Ask HN: What startup/technology is on your 'to watch' list?

Could you please expand a bit on this thought? I personally haven't used almost any API automation tools yet, although I do keep on looking in that direction from time to time.

It would be great to hear another perspective.

I like meat too and won’t give it up unless decent lab grown meat comes around but this comment is the most dissembling nonsense I have heard in a while.

I think I can answer part of this. I worked on building GraphQL APIs dynamically from Rails models as sort of a pet-project at Shopify a few years ago.

It’s not a difficult task, but when discussing viability with the APIs team, the general consensus was that you don’t want your API coupled to your data. Most of the time, you don’t want to expose everything.

Of course, you can start describing what to omit, but now you’re just writing an API design by omission.

Building good APIs is hard, so you want to build the right abstraction - which is not always the easiest one.

I've been using it as a CMS in one of my latest projects, and so far it's been great. The database structure it generates is pretty neutral, and probably the same way I would normally build it. I haven't used their API/GraphQL yet, just ran my own queries.

I am opionated about this, I am sure people can share other perspectives.

When you're operating a CNC machine, as an operator, do you need mess around with internal wiring, schematic, motor controllers? No. You just need a control panel, with DRO and a bunch of buttons, a joystick for manual override, e-stop and a keypad. You're not dealing with the exposed wiring and internals of the machine. Nor do you care (except if you're a hacker, more on this below).

APIs are all things the user needs to do and we allow them specific endpoints to do those things. A lot of modern GraphQL methods allow you to become a "hacker" and get access to what you want. But, after you're done hacking, you want a proper control panel with steel panels and a version number. You, as a user, are guaranteed that interface and you're going to build your world around it. Check out Shopify, Stripe or Dropbox APIs. See what they allow you to do and what they don't.

Here are some reasons why we want an API:

- Decoupling internal resources from the user (user can still be an internal service). We want to be able to change the database, swap it with anything else we want, completely change the schema, whatever... without affecting the user.

- We might require processing/handling of the data, sometimes with help from other microservices before serving.

- We might want to cache read access, although I am sure this is possible with these automation tools.

- We want stability over expediency (although, this is ok to forego initially).

- We want a singular point of entry, aka entrypoint and be able to control it.

- We might want to asychorniously process the request. "Hey, I got your request and I am processing, here is the processing ID" and respond with status code 202.

All these automation tools are great to get a product running quickly. Personally, I would just use straight SQL for prototyping. If you're working on UIs and don't have access to the server, you can just use https://postgrest.org/ and get an API running. However, after you're product has reached maturity, tighten up those endpoints.

The endpoint design is your control panel. Make it look tidy, checkout how others build this panel, engineer it well and your users will thank you.