3 ms·

I feel like projects like this work for simple stuff but as soon as you need analytics/insights or actual business logic, you almost always need to just "roll y

I feel like projects like this work for simple stuff but as soon as you need analytics/insights or actual business logic, you almost always need to just "roll your own" API. Am I wrong? Do other people feel this way? Can anybody think of a few projects they've worked on that would be too complex/a ton of work to make work with these kind of simple template generators?

eatonphil 6y ago
Long-term maintainability is definitely my concern. I don't see projects like this so much as products themselves (maybe I'm myopic) but as core infrastructure. I don't want to ever write the boilerplate again, but I should be able to extend it maintainably over time (hence ejecting or Lua hooks). My goal in building this is to allow myself to more rapidly prototype real, complex applications. It's not there yet but I've got such an application in mind, building toward support for it as I'm developing this.
BlackCherry 6y ago
I think on average you're right. As the project grows, these generators lose some of their initial value and speed. If I were to use something like this, it'd be for rapid development initially for prototyping purposes. Then I'd transition to something more bespoke as needed. If you know all your requirements up front, then starting bespoke from the beginning may be the better route.
lukeramsden 6y ago
Postgraphile allows you to write plugins to arbitrarily extend (GraphQL) schema and wrap resolvers, which is useful for things like interfacing with external APIs etc. It works just fine for me at my current project.
chadhutchins10 6y ago
DreamFactory is basically a paid service for this sort of thing. They support something like 20 types of databases (among many other data sources). They have a lot of features that make the exposed api be good enough long-term. https://www.dreamfactory.com https://www.dreamfactory.com
robmccoll 6y ago
It seems like when working with generators, the trick is to have the right boundaries between generated code, points where you can extend the generated code, and the API through which you use the generated code. If successful, you should never feel the need to hand edit the generated code itself, and you shouldn't need to worry too much about re-running the generator breaking things or stomping on your code.
- deleted 6y ago
  [deleted]
- xgenecloud 6y ago
  >> you shouldn't need to worry too much about re-running the generator breaking things or stomping on your code. Can't agree more! There are code parsers which give out a DOM and then code can be manipulated. But is a bit of work. We are trying this concept in our framework.
jon-wood 6y ago
The sweet spot for things like this is for them to generate the sort of code you'd want anyway, in a way which allows you to selectively replace bits where you need additional business logic or UI customisation. Rails' generators are a pretty good starting point here, if a little bit more verbose than I'd like. They're great for getting the boilerplatey bits off the ground, and focusing on the bits that are unique to what you're doing.
FinalDestiny 6y ago
I’m using Prisma right now and they allow you to manually expose your fields, and they allow you to “resolve” any field as you see fit. If you want to run the original function, you can provide “originalResolve” and call it later. I think Prisma has a great (albeit in progress) way of doing what you’re saying. It also integrates with graphql-codegen so you can generate code for apollo/others
CuriouslyC 6y ago
With postgrest you can add stored procedures as rest rpc calls, and you can always roll a microservice for more advanced stuff. In practice these sorts of auto-api tools make a good starting point as long as they support your authentication and authorization needs.
- rapind 6y ago
  What I like about postgREST is you’re leveraging a mature system for authorization (postgresql roles) rather than rolling your own outside the database and introducing a ton of code and vulnerabilities. Not every application needs roles though, but it definitely feels like the saner approach if you do. Also a nice side effect, depending on the team, is a significant performance boost as your forced to go deep in database land instead of leaky ORM abstractions.
jjeaff 6y ago
Ya, I have very few tables in my db that can be updated directly without needing to pass the data through some business logic, trigger notifications, etc
manigandham 6y ago
Used PostgRest once. We had a project with datasets for sale where all the data was stored in a database and didn't need any updates or transactions. Postgrest was easy to create a self-contained API. https://github.com/PostgREST/postgrest https://github.com/PostgREST/postgrest

eatonphil 6y ago

Long-term maintainability is definitely my concern. I don't see projects like this so much as products themselves (maybe I'm myopic) but as core infrastructure. I don't want to ever write the boilerplate again, but I should be able to extend it maintainably over time (hence ejecting or Lua hooks). My goal in building this is to allow myself to more rapidly prototype real, complex applications. It's not there yet but I've got such an application in mind, building toward support for it as I'm developing this.

BlackCherry 6y ago

I think on average you're right. As the project grows, these generators lose some of their initial value and speed. If I were to use something like this, it'd be for rapid development initially for prototyping purposes. Then I'd transition to something more bespoke as needed. If you know all your requirements up front, then starting bespoke from the beginning may be the better route.

lukeramsden 6y ago

Postgraphile allows you to write plugins to arbitrarily extend (GraphQL) schema and wrap resolvers, which is useful for things like interfacing with external APIs etc. It works just fine for me at my current project.

chadhutchins10 6y ago

DreamFactory is basically a paid service for this sort of thing. They support something like 20 types of databases (among many other data sources). They have a lot of features that make the exposed api be good enough long-term. https://www.dreamfactory.com https://www.dreamfactory.com

robmccoll 6y ago

It seems like when working with generators, the trick is to have the right boundaries between generated code, points where you can extend the generated code, and the API through which you use the generated code. If successful, you should never feel the need to hand edit the generated code itself, and you shouldn't need to worry too much about re-running the generator breaking things or stomping on your code.

deleted 6y ago
[deleted]
xgenecloud 6y ago
>> you shouldn't need to worry too much about re-running the generator breaking things or stomping on your code. Can't agree more! There are code parsers which give out a DOM and then code can be manipulated. But is a bit of work. We are trying this concept in our framework.

jon-wood 6y ago

The sweet spot for things like this is for them to generate the sort of code you'd want anyway, in a way which allows you to selectively replace bits where you need additional business logic or UI customisation. Rails' generators are a pretty good starting point here, if a little bit more verbose than I'd like. They're great for getting the boilerplatey bits off the ground, and focusing on the bits that are unique to what you're doing.

FinalDestiny 6y ago

I’m using Prisma right now and they allow you to manually expose your fields, and they allow you to “resolve” any field as you see fit. If you want to run the original function, you can provide “originalResolve” and call it later. I think Prisma has a great (albeit in progress) way of doing what you’re saying. It also integrates with graphql-codegen so you can generate code for apollo/others

CuriouslyC 6y ago

With postgrest you can add stored procedures as rest rpc calls, and you can always roll a microservice for more advanced stuff. In practice these sorts of auto-api tools make a good starting point as long as they support your authentication and authorization needs.

rapind 6y ago
What I like about postgREST is you’re leveraging a mature system for authorization (postgresql roles) rather than rolling your own outside the database and introducing a ton of code and vulnerabilities. Not every application needs roles though, but it definitely feels like the saner approach if you do. Also a nice side effect, depending on the team, is a significant performance boost as your forced to go deep in database land instead of leaky ORM abstractions.

jjeaff 6y ago

Ya, I have very few tables in my db that can be updated directly without needing to pass the data through some business logic, trigger notifications, etc

manigandham 6y ago

Used PostgRest once. We had a project with datasets for sale where all the data was stored in a database and didn't need any updates or transactions. Postgrest was easy to create a self-contained API. https://github.com/PostgREST/postgrest https://github.com/PostgREST/postgrest