Should I feed my website through the API or not?

Asked

Viewed 145 times

4

If I am developing a site that has an integrated API, for example Laravel, I own a site and an API in the same project

What is the best way to feed the site?

  • I must create a controller which will fetch the API information in JSON and return the HTML?
  • I must create a controller that will fetch the information directly from the bank (thus I have to maybe repeat code in the controller of the API and the website)
laravel api software-architecture

  • If the controller is already on the same server as the database, I see no reason to make an extra request to fetch the data in the API.

  • I imagined the same, but then I have to choose between making an extra request (which is made straight from the server, so I don’t know if it makes so much difference) or repeating the code in two different places, which makes maintenance difficult

  • And if the API already provides all the data, why do you need a controller? You can’t make the application serve directly in the API?

  • Yes, but the API provides separate information, for example, people, products, brands, if I’m going to make a page that loads the 3, I need to either load by ajax, or make another function that calls the 3 requests

  • API with integrated website is still very confusing for me

  • And why, then, not define a Service that provides the data for both the controller and the API?

  • Well, interestingly, I don’t know much about service, I’m going to do a little research on that, so thank you @Andersoncarloswoss

Show 2 more comments

1 answer

5


Which one best meets your need? Use this one. And only you can answer this.

Today there is a tendency to use API and use a frontend web that consumes that API equal to one frontend desktop or mobile, or some service would do. This has its usefulness there, and in some cases it is the best to do, especially when it is a web application and not a website. Although I am generally a critic of the web application, in most cases it should not be an application or it should not be web. I speak of the frontend.

If it is a website usually the traditional approach of working with the rendering of the page format be done on the server by view of the MVC or otherwise.

In this case there is no reason to have an extra layer. Only the view should be different, one generates JSON and the other generates HTML. If you need a controller different, or is doing something wrong or is using a rigid technology that does not meet the need.

Repeating the code in two places shouldn’t be an option. Even if the technology and/or architecture does not allow, it can still abstract the execution in functions in a separate service.

Ideally the controller should serve both well, if it is complicated, at least make him meet his real vocation which is to deliver the data to the view.

I see a lot of people writing that the logic of the application should be all there. I must have written it myself at some point. But then again, this is wrong, the controller must be the communication logic of the model with the vision. Execution that should not be in the model, must be in a specific part that is connected to the controller, but not directly. Of course, if it is simple, it has no use in more than one place, it is not wrong to embed right there.

Keep in mind that the actions of the controller is defined by how it receives the data and how it sends it, not the processing of the data. Not directly. There is no repetition, let alone hurt the DRY. Use a service.

If the API is lower level and the frontend is higher level, just use the little blocks of Lego loose in the first, and join them in the second. That’s why the processing should be separated when needed.

The lost art of abstracting

Today people are so worried about following cake recipes patterns, make crazy that she doesn’t understand architecture, that forget the basics of the basic, the foundation.

There are 3 things that revolutionized programming:

  • Code writing at a high level
  • Modularization
  • Automatic management of memory

The second in its essence is to know how to use functions for your benefit, to avoid repetitions and achieve the DRY.

Today most codes do not meet this, many experienced people do not even realize it. Code organization is more important than following the master. Understanding the right level of abstraction helps you more than decorating ready-made models that may not be the most suitable for your problem.

For example, initially there was ASP.NET MVC and ASP.NET Webapi. Made by the best engineers in the world. It took them a long time to realize that everything was repeated and then they made ASP.NET Core to solve this problem.

  • Beautiful answer, I avoid at most repeat code my problem is to know where I should put each code (this in the Readable), if I make a select of people that also brings their address, often I do not know if I should do it directly in the controller or make a function in the model, even if I don’t seek people along with address more than once

  • Thank you. In the model goes to what refers to the object, in the controller goes who needs to control the communication of the layer and eventually something that needs to process before going to one side or the other.

  • That is in my case I must select with Join in the model, and in the controller organize this and other information to return the view?

  • 1

    It depends, but it’s possible, so maybe you should see this: https://answall.com/q/305207/101

Browser other questions tagged laravel api software-architecture

You are not signed in. Login or sign up in order to post.