Moseskamau338's avatar

Using Laravel for Large Scale SaaS and Microservices

So I've been recently exploring how I would go about implementing a SaaS Point of Sale product for the food industry. There are quite a lot of modules and data points that need to be handled properly for the software to work as intended. While doing my research, I've come across all sorts of tech stacks, database systems, headless CMS plus much more, and obviously, am confused.

I know Laravel can do some serious backend systems but am not sure how I would apply it for the following questions:

  • How do I design a microservice architecture with Laravel?
  • How would database relationships work?
  • How would my database setup look like?
  • What would be the best choice for a DB?
  • How would I handle authentication for a multi-tenant app? Keycloak? Auth0?

It's questions like these and many more that get me confused and I can't find one place with the answers stated precisely.

If you have an experience with this challenge or you know some nice resource you can point me to, I would greatly appreciate it.

0 likes
5 replies
martinbean's avatar
martinbean
3 years ago
Best Answer
Level 80

How do I design a microservice architecture with Laravel?

@moseskamau338 Laravel is a full-stack framework. It’s not suited for microservices in my opinion.

How would database relationships work?

If you’re asking this, then you don’t need micro-services. If you have related data that doesn’t have a clear boundary, then you should not be separating those codebases at all. All you’re doing is moving your database joins to be over HTTP, which is the worse thing you can do and the network is the slowest form of transferring data in the computing stack.

Don’t jump on the microservices train Just Because™. You should only be using microservices where you’re absolutely sure you need them, because they introduce far more problems than they solve. If you’re in any way unsure you need microservices, then you most likely don’t. And from the project you’ve described, there’s very little to make me think you actually need microservices.

My rule of thumb is, if you have a model that depends or needs a model in another “service”, then there is not a boundary between those two entities and they should not be in separate services.

Moseskamau338's avatar

@Sinnbeck I loved the read. I actually think that the question behind my question was which stack I would use if I wanted to build a SaaS multi-tenant application at scale and the article provided amazing insight on that.

But the piece of the puzzle now remaining is what approach I will use for multi-tenancy.

I tried this multi-tenancy package but I couldn't run my test suit and deploying it to a different developer machine was incredibly difficult.

My concerns are that if I use an identifier for all tables,

  • it might be a bit heavy to scope queries at scale
  • If the client says they want to move it on-premise, it would be hard to get all the stringed data

How can I use databases for each client, in a single domain setup, and have a smooth testing experience without running into issues where that setup only runs in my docker container? Is that even the right approach?

Please or to participate in this conversation.