Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Frontend tooling has never been better than it is today.

What's the library or design pattern to consume a REST API in React or any of the mainstream front-end frameworks? The only thing I'm aware of is Ember Data but Ember is apparently not cool anymore, and I couldn't find a suitable replacement.

I'm asking because in all the projects I've been involved with, consuming the backend API always felt like a mess with lots of reinventing the wheel (poorly) and duplication of code. I can't believe in 2020 there's not some kind of library I can call that will give me my backend resources as JSON and transparently handle all the caching, pagination, error handling (translate error responses to exceptions), etc and people have to do all this by hand when calling something like Axios.

In contrast, Django REST Framework handles all that boilerplate for me and allows me to jump right into writing the business logic. It's insane that ~30 lines of code with DRF (https://www.django-rest-framework.org/#example) gives me a way to expose RESTful endpoints for a database model to the web with authentication, pagination, validation, filtering, etc in a reusable way (these are just Python classes after all) but the modern front-end doesn't have the client equivalent of this.



> I'm asking because in all the projects I've been involved with, consuming the backend API always felt like a mess with lots of reinventing the wheel (poorly) and duplication of code. I can't believe in 2020 there's not some kind of library I can call that will give me my backend resources as JSON and transparently handle all the caching, pagination, error handling (translate error responses to exceptions), etc and people have to do all this by hand when calling something like Axios.

If you look at 20 REST API's you'll probably see 30 different patterns for pagination, search/sort, error responses, etc. There have been a couple attempts to standardize REST such as OData but I think it's safe to say that they haven't been very successful. It's kind of challenging to build standard reusable front end tools when everyone builds back ends differently.


Ember has somewhat solved that problem though.

You have the concept of data adapters which would be clients for your API (you can make a custom one if extending the existing ones isn't an option) and the rest of the application just interacts with the equivalent of database models without ever having to worry about fetching the data. You could swap the data adapter without having to change the rest of the code.

We seem to have lost this with the move to React though, and even the hodgepodge of libraries doesn't provide a comparable replacement.


Haven’t used it but aren’t there things that can connect to a swagger API spec and do some of the heavy lifting for you? I agree that the network layer in frontend is tedious to implement, things like GraphQL and Apollo attempt raise the abstraction level. What I would really like to see is something even more abstracted, e.g a wrapper around indexdb you can write to that syncs periodically over websockets to your server, more similar to the patterns we use on mobile.


It seems that you are describing pouchdb: https://pouchdb.com/


You're right Pouch completely slipped my mind, it's a great solution. But what about something more generic on the backend that wasn't database specfic, some sync engine you could put in front of whatever database you wanted. Can you do something like this with Pouch?


> What's the library or design pattern to consume a REST API in React or any of the mainstream front-end frameworks?

For React, its out of scope; anything that you can use in JS for this can be used. If you are using a state management library, that's probably more relevant to your selection here than React is.

REST is also too open-ended for a complete low-friction solution, but, e.g., if its swagger/openapi, there's tools that will do almost the entire thing for you with little more than the spec.

> The only thing I'm aware of is Ember Data but Ember is apparently not cool anymore, and I couldn't find a suitable replacement.

Ember Data is definitely a valid choice. It may not be hyped right now, but that has little to do with utility or use in the real world.


The graphql frameworks - like Apollo - give you that. I haven't used it. For basic caching the state management frameworks work pretty well, but it is a lot of layers when you add Redux or Vuex to your stack. It works well for us though and I find it much easier to reason about than the old jquery spaghetti code style.


I hear you. I find myself needing to reinvent the wheel far too often to traverse the boundary between the client and server. I also feel that it shouldn’t be this hard. Apollo client and relay solve this problem for GraphQL APIs (quite nicely IMO). What’s missing is an Apollo client for non-GraphQL APIs.


For what it's worth GRPC-Web is a pretty nice solution here.

My team generates backend stubs from our GRPC spec which allows us to jump right to implementing our business logic.

Frontend projects make use of the GRPC-Web client codegen to make calling the API simple and type safe (we use typescript).

We mostly use all the official GRPC tooling for this. We write backends in golang and dotnet core so GRPC-Web is supported quite well out of the box.

I wrote a slightly modified Typescript codegenerator to make client code simpler as well: https://github.com/Place1/protoc-gen-grpc-ts-web


Yeah, after experiencing type safe APIs + editor integration with TypeScript I don’t think I can go back.

There are, of course, other solutions besides GRPC.


React Query.


React-query.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: