undefined | Better HN

0 pointsmamcx2y ago0 comments

One major reason is that both developers/customers who ask for it think in UI first, all the time.

Most developers I know are at the far-end of development practices (one of the ERPs I integrate has tables like `F0001, F0002, ...` and fields `F00001, F00002`), and this ERPs then uses old tools like Cobol, Fox, (Old) Delphi, (OLD) VB where it has a better UI history.

And it causes to be very hard to build an API (you can't image how much torture is when an ERP vendor says "we have an API!" instead of using plain text or direct SQL)

For this, you need people that know how to do good APIs. And the good API for an ERP is NOT Rest, GraphQL, JSON, ... (ideally, you need a DB!)

0 comments

arnorhs2y ago

Well the UI-first thinking makes more sense, since in most cases you are solving process-problems, which involves "what does who do when?"

It's hard to communicate a process through a REST API. Sure you could document it incredibly well, maybe even have every part of your ui represented by an API endpoint, but ultimately, due to the number of customizations involved with each ERP view, you'd end up with some sort of bastard, which was never quite the same as the real deal.

j / k navigate · click thread line to collapse

0 comments

arnorhs2y ago

Well the UI-first thinking makes more sense, since in most cases you are solving process-problems, which involves "what does who do when?"

j / k navigate · click thread line to collapse