Introducing the SJGAR stack
In this article I will introduce you to a new software stack that can be thought of as a spiritual successor to the MEAN or MERN stack. The technologies in the SJGAR stack were carefully combined to create something where the whole is greater than the sum of its parts. Focus on your customers, on business value and the developer experience. Do more, and keep things simple.
If you want to find out why the mix of Serverless, JavaScript, GraphQL, AWS and React could be interesting to you please read on.
Disclaimer: This is not a sponsored post. All views expressed in this article are mine and may or may not be shared by my employer.
The Years of Turmoil.
I remember writing software in the period roughly between 2005 and 2015 where sometimes it could feel like every week something new was thrown at us. We were transitioning from desktop to the web and then cloud and mobile. We were just getting good at Object-oriented programming when a shift towards Functional Programming required us to rethink our mental models around our code. Cloud scale computing brought us from solely using SQL databases to study and use NoSQL databases. We went from embracing XML and SOAP to transitioning to JSON.
“Focus on your customers, on business value and the developer experience. Do more, and keep things simple.”
Note: If you would like to skip the story you can skip to the ‘Introducing the SJGAR stack’ paragraph in the full post.
Looking at JavaScript alone there was also a lot of turmoil. The language started almost as a toy language to glue together simple elements on a web page. Then it slowly but steadily grew into becoming the most widely used programming language on the web. It even moved on beyond the browser and started to conquer the server with Node.js. A realm where Java and .NET were dominant before, now had to create some room for people starting to use JavaScript on the server.
On the web, framework after framework was becoming popular. Much to the point where they are still being refactored away ten years later. I remember moving from jQuery to Backbone or Knockout. I used Ember a bit and then also Angular. All of these seemed to offer some improvements over what was previously there. There were still enough rough edges however. It was clear we were not there yet.
Enter the Calm and how we used the SJGAR stack for the first time.
In 2015, I got the chance to work on a corporate startup project that was completely greenfield. We set out to create a platform with web and mobile apps with state-of-the-art user experience, and we wanted to fail or succeed fast. This meant we had to ensure a short time to market. We had to focus on developer experience and productivity. After having tried some pieces of technology on smaller projects, this was the perfect chance to put them together and figure out if they would play nicely together. In theory, it should all work, but previous experience had shown that you really need to start using them for a decent amount of time to figure out if the new advantages will really outweigh the drawbacks.
“It worked. It really worked.”
We built a web application using React and an accompanying mobile app using React Native. The backend was built using AWS Serverless technologies. We used DynamoDB as the single source of truth for data. The built-in event triggering system was used to run some Node.js code in a Lambda to stream this data to a managed Elasticsearch cluster, so we could support the search and query capabilities we needed. We created a GraphQL API using the reference server implementation graphql-js (Apollo Server and Client weren’t a thing back then). Again this was run in Lambda. To make sure the web application was performant enough for our end users we used a Lambda to implement Server Side Rendering (Gatsby and Next.js also weren’t a thing back then). We also used the Serverless framework, a bit shaky at that time, to write our infra as code.
With a handful of full stack engineers we were able to deliver this project successfully to production. We could deliver new versions of our microservices independently, and we would do this multiple times a day.
It worked. It really worked.
We started with almost zero costs for infrastructure. The most expensive service was the Elasticsearch service. The other services would easily service our first customers on the free tier. I think we never spent over 100 euros a month. Without Elasticsearch it would probably not have been higher than 10 euros a month. We launched and started running ad campaigns to lure customers to our new offering. For these ad campaigns we were spending over a thousand euros per month. It was clear that we now could go to the business and tell them we could do innovation projects with IT running costs of close to zero.
I remember we were able to move some logic from the web app to the authentication provider (we used Auth0 back then since Cognito was still a bit too new) by just copying some JavaScript code. Similarly, we were able to move code from frontend to backend. More generally we were able to take what we learned in a certain context, and apply it to a different one. JavaScript allowed us to learn a single programming language and write code for the Web, Mobile and Cloud. React allowed us to use a single framework to structure applications and do the state management for both Web and Mobile. Using Flexbox we could even apply the same UI layout system in these apps. With the complex and time-consuming nature of layout work, it was great that we were able to reuse our knowledge and tools to enjoy a great productivity boost.
Going Serverless meant we did not have to spend time on managing servers. The code and the system would just work. No disks filling up, no security patches to be applied, no certificates to be updated. AWS had given us a platform with great performance and stability. Everything would just run.
After running this project in 2015 and 2016, in the end it was shuttered because it did not align with our business goals. Only later I came to realize this set of technologies would stand the test of time, and would do so pretty well.
Read the Full Article.
Read the full article here https://www.sjgarstack.org/blog/20201028/introducing-the-sjgar-stack.
About the Author
Vijai Ramcharan has been working in the software engineering field for over twenty years. He is passionate about using software technology to put a smile on the users face, and help them get something done. He likes to peel away layers, both in software architecture and companies, in order to simplify things and get stuff done.
Currently, as an innovation architect, he is helping to build a highly talented team at NN that is at the heart of a technology infusion for the company. The team is helping the company to transform into a fintech and serve their customers even better. The group is bringing working software, a helpful attitude and the spirit to learn from each other.
If you are a software engineer or architect interested in what they are doing send out an email to vijai.ramcharan @ nn-group.com. You can also find this post on the NN Tech Blog.
Besides working on software, Vijai loves to spend as much time as possible with his wife Sharmila and five-year-old son Jayce. Together they like to travel around the world, where they enjoy the sun, local food and culture.
Originally published at https://www.sjgarstack.org.
