If you're like many of our clients, you have a large and long-standing investment in your Ruby on Rails architecture. You've been upgrading over the years, and navigating your way through all the various changes that come with each new version. You probably have front-end code peppered with JQuery, some React perhaps, some HAML, and some ERB. The accidental complexity in all that builds up, which adds to the tribal knowledge needed for developers to be successful and productive in your application.
At the same time, given the current lifecycle of Ruby on Rails, which is quite mature, you might be wondering "what's next?" How can you continue to innovate while leveraging your current architecture and data model?
Over the past 18 months, we've proven out a very exciting model here at Dhamira. It starts with introducing Hasura to provide an easily programmable GraphQL API interface to your Postgres data. As soon as that is installed and configured, which can be done in a matter of hours, you are now able to have modern, React based user interfaces deployed statically, and interacting directly with your data.
This is a big deal for a number of reasons:
- You now have an environment against which you can develop and deploy greenfield applications, leveraging your investment in your data and data model.
- You can use these statically deployed React applications to completely change your performance and scalability profile.
- You'll have greater separation between your user interfaces and data, with much less business logic in between. You won't miss Rails controllers and the process-based scalability bottlenecks (and cost) that they incur.
Let's take a look at what this looks like. Here's a simple diagram showing a traditional Rails architecture:
Everything to the right of the "Static Assets" folder above drives your operations costs, in terms of ensuring you have the proper capacity at the proper time. You should also note that your data in the above diagram is sitting behind the process-based scaling of Rails application servers, causing a significant performance bottleneck. This bottleneck is often addressed a couple of ways, through horizontal scaling of application server instances, and through caching at the UI layer.
Introducing Hasura and statically deployed React user interfaces flips this around, putting the most requested items to the left of the Rails framework. Here's how that looks:
In future articles we'll go in depth into each of these areas, with examples, but as an overview, you'll see that Hasura allows your data to be moved outside of the Rails barrier. Hasura itself is multithreaded and highly scaleable out of the box. You can apply authorization via JWTs, or webhook requests, controlled by your Rails application, or can integrate directly with Okta or Auth0 if you're already using one of those services.
Marrying this with new, statically deployed React user interfaces, massively scaleable as static assets served over commodity CDN's, you can realize incredible performance gains in allowing your simple database reads to happen directly between your user interface and Hasura via GraphQL queries. Hasura can also proxy complex writes, and reads, to your Rails REST API, allowing you to incrementally move more and more of your application out of the Rails box and into the world of Serverless.
We've only scratched the surface here, and we'll be doing more articles and a webinar coming up. If you're interested in learning more about how Hasura and React can catalyze new development in your organization, get in touch!