Single Page Apps (SPA) + APIs seem to be the default nowadays over more traditional Multi-page apps Ruby on Rails / PHP type server-rendered HTML.
I want to write an article about why I think MPAs are still a valid a nice way to make applications but I'm not sure where people are at right now besides they seem to be picking SPAs almost exclusively.
- Was React + APIs the only thing you learned?
- Why did you pick SPAs personally?
- Why did your company pick a SPA if they did?
- Why do you think SPAs became the default for most orgs? Or do you think they aren't?
If you have no idea what the difference between a SPA or MPA is then I am curious about that as well (I just want to hear from you guys I guess 🤗).
Cheers!
Photo by Javier Allegue Barros on Unsplash
Top comments (9)
Hey Gage,
I’d love to hear a modern take on MPA’s. I’ll admit, my default architecture for any application more than just a static business landing page will tend towards using React with Next.js to get the best of both worlds. Maximise component reusability and still capable of serving out individual pages instead of loading the entire application. But this is also all I have known for the last few years - so it seems hard to change approaches without some really significant benefits upfront.
Yeah Next.js is great, I can see why people like it. Maybe you're building more of a informational website / blog, but what do you do if you need to save something to a database? Or maybe issue a stripe refund? Or is this not an issue in what you're building?
Oh yeah, almost every application I work on now will utilize a serverless backend where feasible. I'm a heavy AWS user myself, so I would frequently use DynamoDB and S3 for data stores, and Lambdas via GraphQL or API Gateway for data access (leaning more towards GraphQL these days for the benefits of data subscriptions), and EventBridge with SQS/SNS for event queuing where needed (like handling failed payments and rollbacks required from stripe). I wouldn't go as far as saying I'm always building a microservices architecture pattern, because many of these applications are simply a 1-2 person developer team. But with this combination of tools, we still get great modularity and separation of concerns between the front end site and back end resources. Ultimately, we're aiming to keep the Next.js side of things as focused on being a view into the data the application works with, with the heavy data manipulation working in isolated serverless components.
Interesitng 🙂. Is this hard to dev on locally? Do you just dev on prod/staging? Or do you find ways to mock things out?
I should try lambda functions, never really done it.
Definitely worth trying out Lambda in my opinion. And no, not too hard to dev locally with this type of setup. It's might not be as straight forward as having direct access to a local database etc, but there are plenty of tools emerging that can really help mock out these serverless resources, and deploy everything in a multi-stage style environment. If your keen to check out AWS Lambda, might be worth looking into the AWS Amplify toolkit. It takes away alot of the initial complexity of setting up functions, and provides the reuqired resources to develop, mock, and test everything locally before you push to the cloud. Here you can find the general process of setting up a GraphQL server and Lambda backend using the AWS Amplify CLI docs.amplify.aws/cli/usage/mock
Very cool, that does look like that would help.
This might be a stupid question, but I'm wondering what were you doing that caused you to pick this stack in the first place, Were you using another framework before or is this the first one you tried?
Mostly I was using Ruby on Rails beforehand, but the main choice to venture down serverless was not wanting to maintain the underlying OS and systems behind each database and general backend systems. I spend probably 80%ish of my time now writing front end code, and the remaining 20% with backend initial configuration and deployment. For me, it's nice to not have to worry about running the latest container, or be too concerned about partitioning off and sharding DB tables etc.
Yeah that's a very big benefit I do admit! We used to use Create React App at Podium and that was one of my favorite benefits, never having to worry about the Webpack config under the hood. Things would generally just work and we would get upgrades for free.
So were you using Ruby on Rails as just an API? Or were you doing server rendered pages? What were you building with them? They must have been pretty successful if you ended up having to shard DB tables 🙌
Hahaha. Successful is a very subjective view. These were niche CRM/ERP style applications that were server rendered pages as well as API, and rightly or wrongly the sharing strategy was only in place for some limited multi region use cases, not necessarily due to database load etc.