1

Lets say I am building some large application ( multi-page app ) using Laravel. And laravel will allow me to make an API and a website on the same application.

Since the website and the API will communicate with the same database, I was wondering if it is better to consume the same API for the website using some javaScript framework like Vue.js.

So this means I will make single entry point to the database for all the clients ( web , mobile..etc ) what ever call this API.

And my plan is to make:

  • ApiControllers ( communicate with the database and return data )
  • WebControllers ( return blade views which will have vue.js components inside to consume the API ). There is no communication with the database in these controllers.
  • What do you suggest?
  • What will you do in this case?
  • Is this a good idea?
Improve this question
3
  • Does the website offer the same functionality as the mobile clients, or does the website have functionality that isn't (and shouldn't be) available to mobile clients, like an administrator part?
    – Bart van Ingen Schenau
    Feb 15, 2019 at 7:02
  • Please don't add bolding to random words in your question. It makes it harder to read.
    – Eric Stein
    Feb 15, 2019 at 14:46
  • @BartvanIngenSchenau yes, both will have the same functionality.
    – rook99
    Feb 16, 2019 at 16:33

1 Answer 1

Reset to default
3

This is a general answer, and may or may not apply to your specific use case. Remember to always think about architectural decisions, as there is no "one size fits all."

Typically, I would use the same services to drive all front-ends, because then you only have to maintain one set of these services, instead of multiple services. You are trading off the extra cost of maintaining multiple versions of the services for the extra cost of ensuring your services can support all platforms. You also have to be cautious as you need to develop in a way that is conscious of the fact all your front-ends will be calling the same back-end.

This may mean you should secure certain endpoints so they can only be accessed by a certain front-end (there are many ways to go about it, so if this is a need do some research on the topic), or that you might have to have a more in-depth deprecation plan (if you use a mobile app, users may have old versions). Maintaining multiple similar versions of the same code is a massive PITA.

Improve this answer
2
  • Thank you for your help. What kind of questions should someone ask, to decide which one to choose between the tow (preloading data with view Vs ajax requests) ?
    – rook99
    Feb 16, 2019 at 16:33
  • @rook99 There are two concerns I can think of: Data security and user experience. In a view, you probably are loading the data on the back-end, so the user doesn't "see" the raw data, but with an ajax call, the user can always see it (the browser is sending/receiving the call, not your server). If your services are secure, there's no reason to worry about the user seeing the shape of your data in most cases. The user experience piece, a view loads all at once when done, an ajax call allows partial loading or lazy loading of the page.
    – Marshall Tigerus
    Feb 18, 2019 at 17:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.