Hey @dserber… Yes, the situation you describe is exactly what I call the “API ghetto” issue. As for the question:
It’s potentially possible, to a certain extent. It depends on what exactly one wanted to do.
The node “http.request” module is available in server side actions – so theoretically you can do your own API Connector type calls (GET, POST, etc.) from directly within a server-side action. And you could asynchronously makes those calls, await the responses and then massage/combine the data into a consistent format.
Further, that format could POSSIBLY? be compatible with a “real” custom data type that you have defined in your app.
At present (and maybe not ever, I’m not sure) you cannot return a custom data type itself. You have access to the primitive data types like so (and those can be single values or lists):
Now INSIDE of a server-side action, there is no capability to modify Things in the database nor to create new ones. That is still the exclusive province of the Create and Make Changes actions.
So I think one still has the problem of having these lists of data objects and needing to iterate over them in a Bubble workflow (like a recursive workflow or schedule API workflow on a list) in order to create “real” database Things out of them.
So, in a way, I think what we see here is the origins of the “API ghetto” problem. You can build your own “API Connector” type of things with a server-side action, but you still have the same problem as in Bubble’s API Connector, which is that you cannot:
- Receive data from an API and spit it out as a custom data type. (Just like in the API connector, I cannot say “Hey bubble, this JSON response is a (for example) ‘Car Thing’” and have Bubble create the individual Car Things that come across in the response.
Anyway, I can’t figure out even a tricky hacky way around this. (Note that I have not played with using http.request module in my own server-side action efforts. Mostly because it seems to me that I will hit this problem and it just won’t solve the API ghetto issue.)
What I’ve been doing in server-side actions is making interesting new modules that are primarily around filling gaps in certain list type operations (e.g., a Bubble version of getIndex() – tell me what position object x is in a list of objects), utility functions for creating certain types of primitive lists, some actions that are akin to logical operators, date/time manipulation things, etc.
The idea is that each of these is a pretty lightweight bit of code and you could conceivable chain the together in a workflow to do things that are very hard to do right now.
(The issue one runs into with that is that at present SSAs are very very slow to return – this may be a “bug” in terms of Bubble scheduling these actions or maybe its just that SSAs eat up a lot of what minimal CPU capacity we have. Bubble’s @marca is working on this. It remains to be seen what kind of performance we can expect from SSAs once Bubble does optimize or fix any actual issues that SSAs currently have.
But my fear is that we may not be able to achieve any performance advantage in this way. There would still be cool things that SSAs could enable if SSAs that operated on a single object were suitably fast, but one of the thing that excites me about SSAs is the potential for filling in some of the holes that would make Bubble more of a true array-oriented language.
We shall see…)