0

I'm building an API that's intended to be consumed by an iOS app as well as a browser-based Web Application (using React / AngularJS). The API is being developed in Laravel.

What is the best way to structure this? Should the API and the Web Application be apart of the same Laravel Application, or should the API be an entirely separate entity that just returns JSON to whatever client requests it? In that case, I suppose my Web Application would interact with the API as though it were a 3rd party API

djt
  • 7,297
  • 11
  • 55
  • 102

1 Answers1

0

We we've had a grown monolithic application and decided to split the code up, into repositories called "core", "frontend" and, new to our family, added "api".

That is, we are using the Microservice pattern and it works well for "us".

Our core/frontend repositories are CakePHP but the API is written in Laravel 5 using the jsonapi 1.0 spec.

We're quite, if not to say, very happy with this approach. The only canonical thing it the representation in the database. Business logic and code is redundant. But an interesting lesson learned is that we uncovered quite some bugs due this in the existing code base.

The clean separation is important to not be bound too much to one technology. We may want to replace the "frontend" stack with a node application talking to the API. We may want to replace the API with something else later.

Of course this comes with huge amount of work, resources, etc. but not being able to act due a monolith is worse in our view.

mark
  • 6,308
  • 8
  • 46
  • 57
  • Very interesting! Thanks for your response. However, why are there database redundancies? – djt Nov 22 '15 at 14:09
  • The DB is canonical, means e.g. every permission model has to be implemented separately within the layer accessing the database (=redundant). It's not just permissions but quite other things too. But, for us, worth the extra effort to be able to "move on" to other things if necessary. – mark Nov 22 '15 at 20:38