8

For a web app I am working on I have a pretty basic relational database. I access this database through a RESTful API and generate the markup in React once the data is retrieved.

If I find myself constantly manipulating/processing these JSON responses on the client-side just to structure these objects into more friendly structures for my UI, is that a sign that perhaps I am doing too much on the client?

I am relatively new in the industry to begin with and I am more concerned with knowing when I should bring these things up to another developer who is perhaps working on the backend in question.

This perhaps can bleed into a broader question about REST APIs for Web Apps in general:

Should I expect the responses to my data fetches on the front-end be already structured according to the UI's requirements or would I be asking for too much?

A good example of this would be a category list for a 'Products' page. Is it reasonable that I would fetch the total list of products, and then build the category list from that data or should I expect to have an already structured list of the categories, etc. in the response object when I initially set out to fetch the list of products?

Improve this question

4 Answers 4

Reset to default
3

Your approach will depend on whether the web app is the only user of the backend application or not. It may also depend on what your development team (in this case you yourself) are more skilled in: backend or frontend development.

My preference is to have as much logic as possible in the backend app and as little as possible in the frontend. This is due both to my skillset and also to my conviction that business logic is easier to implement and test in the backend (which may be biased, of course).

So what I would do would be:

  • If your frontend is the only user of the backend app, align all APIs so that they are easy to consume by the UI and provide data as closely fitted to what the UI presents as possible. This way your logic is almost all in the backend (easier to develop and test IMO) and the frontend can concentrate on just presenting the data without dealing with much business logic.
  • If your backend app has other users apart from the frontend, or you have to communicate with a backend app written by someone elase where you have little control over the API, I would consider writing a Backend-for-Frontend (BfF). A Backend-for-Frontend is a backend app which acts as a proxy between the UI and the "real backend". In this app you can transform the data from the backend's format into a format which is ready to use by the UI. You can then have a very simple frontend app and all business logic in the BfF. Essentially, the BfF is a facade which allows you to use the approach described in previous bullet point when you can't directly change the backend app's API to match the UI.
Improve this answer
3
  • I really like your Backend-for-Frontend concept!
    – Graham
    Mar 13, 2018 at 14:42
  • Would your BfF concept be synonymous with a 'three-tier architecture'?
    – connected_user
    Mar 14, 2018 at 17:17
  • @connected_user That's an interesting take on the problem. In a way, they are similar, but only if we assume that the "real back-end" services act as the data tier. This is usually not true since these services contain some kind of business logic of their own most of the time.
    – Michał Kosmulski
    Mar 15, 2018 at 9:44
6

It really depends on your target audience for the API. If you intend on publishing a public API, then you really need to design toward that. If the API is strictly to support the UI, then let it be built ad hoc.

However, this is one of the uses for GraphQL and Falcor (or others like it). GraphQL has a higher learning curve, but allows you to map requests for the precise data you need to display across web services. Your public API remains untouched, and you have this unified query language to consolidate the requests for data into one. Since GraphQL usually lives in an API proxy of sorts, it allows for some intelligent caching.

It comes with a high learning curve, but you do gain a lot of power for your investment. Weigh the costs against your needs. If your API is pretty simple, you can delay looking at this until your needs really do grow complex.

Improve this answer
1

In the case where the API's primary purpose is to push data into a single web app, I think its acceptable structure some (but not all) of the methods of the API to be tailored to the web app. Just make sure you've got some general API endpoints that can be used for more generic purposes later if those requirements pop up quickly.

I think sometimes we give ourselves more work than needed by decreeing layers in our applications necessarily, or by strictly

Improve this answer
2
  • I agree. However in my case the processing of the data into UI friendly object structures is going to happen anyways. I guess I am more confused as to if it should happen on the frontend, or if the frontend should expect it to happen before it arrives there thus making my frontend components strictly responsible for rendering markup, etc. I would like to know if it is a common practice to structure the data in a way where the frontend components only concern is to render markup (as little processing as possible). What is the 'ideal' in these situations with a web app?
    – connected_user
    Mar 12, 2018 at 16:20
  • 1
    Like a lot else with software, there's really no 'ideal' because it can vary with a lot of factors inside your app, like how sure are you that those UI's will not change? If they are likely to change a lot, it would prob be better to leave the service more generic. However, you have to balance the generic-ness of your service against the query performance you can get if your API knows how to serve up all the data for the home page inside one request. You're best bet is to just take a stab and see how your decision is impacted by the next round of changes to the app.
    – Graham
    Mar 12, 2018 at 18:50
0

I am not sure if this short answer would help you. Normally I dont structure the data as per client UI and ensure to send enough information back to client and let client create model specifically to meet UI requirement. This helps me to keep client side concern separate from server. Also why should server even think if consumer of api is web app, mobile app or even desktop based wpf application.

Improve this answer
2
  • 1
    Okay you raise some valid points. However I am going to move the boundaries of what I am asking a little bit: I realise that the database structure itself shouldn't really be concerned with UI, however would'nt it make sense for the design of the REST responses themselves to be concerned with UI? We are not making a public data API, we are making an API that retrieves data to generate markup in our app <-- wouldn't this fact alone give justification for UI-oriented response objects?
    – connected_user
    Mar 12, 2018 at 13:24
  • probabaly if you can provide some concrete example with sample, we can discuss further.
    – rahulaga-msft
    Mar 12, 2018 at 13:53

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.