0

I've been developing several front-end web-applications recently that bind against a database using a RESTful CRUD api.

I've noticed a massive amount of boilerplate code going into defining the API. For example, on the back-end I define a db-schema, controller, api endpoint, and view-model. On the front-end, I expose events, consume the view-model, bind my data, and hook up my UI.

Instead of re-implementing a set of CRUD API actions each time I add to my db-schema, it seems it would be easier to create a management system that would automatically create API actions based on db schema. Then implement a similar generic binding on my front end.

Is there a design pattern, development process, developing methodology, etc. for this?

  • Have you considered GraphQL? – Eric Stein Oct 31 '18 at 18:49
  • That seems close to what I'm looking for. Is there something better to call GraphQL than a "query language"? Is there a principle behind it? Competing libraries? – Nathan Goings Oct 31 '18 at 19:57
  • What about Couchdb? – Yana Agun Siswanto Nov 4 '18 at 0:02
  • Instead of exposing CRUD endpoints, have you considered creating endpoints for specific business operations? There are far fewer of those. – Robert Harvey Nov 30 '18 at 22:07
  • @RobertHarvey In my case, I'm performing CRUD+List operations on several lists—That is, I'm adding 5 operations every time I add a new field/table. I've been playing with a new experimental concept but my coworker thinks Swagger/OpenAPI would be a proper, well-supported solution and I have to agree. – Nathan Goings Nov 30 '18 at 22:12
0

You basically have three options

  1. Hand code the boiler plate
  2. Generate the code with templates
  3. Implement a generic query interface

The problem with 2 is that generally you do have some specific methods that you want to use in addition to the standard CRUD ones. GetCustomerByPostCode or GetRecentlyLookedAtItems etc. You end up tweaking the generated code to your needs.

The problem with 3 is that A the queries aren't limited to the ones you predefine, and B sometimes the SQL query your query language creates is less performant than one you could write yourself.

In my experience 1 isn't a bad solution.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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