I’ve recently started to think about how other applications might want to interact with yours. Say you have a CRM system you may want to programmatically create a new contact or get all contacts from another source. As such it might be a really cool feature where for any existing actions within the application such as create contact a create API button could be selected during the planning phase or at any point to automatically create the API and add it to a library - a swagger file could then be auto-populated. I’m almost wondering whether any actions that are created within the app should automatically have an API created (this could be optional).
My AI Dev Kit (ADK) scaffold app was built API first. They are all internal use only for now, but this strict front/backend architecture means I could open them up for external use if needed.
This kind of design planning is something that is removed from most non-techie users of AI dev platforms. Which is a real problem, as down the road it will be harder to add in.
I wonder if platforms like Replit will eventually provide a better process that forces users to think about these things when they are building an app?
Wouldn’t you want to build a separate API for external use?
I remember in my early days of Replit it felt like there were a lot of “Here’s a critical infrastructure decision you need to make…” I wish there was more of what you’re saying, where the Agent pushes you into thinking through aspects that will impact your application long-term. Doing so would definitely have saved me some time in certain places! ( at you OAuth)
It may have been just the way I always intended the design to be, but my entire architecture is already doing this for an industry specific CRM. It may not be a button, an internal API is created and used to do the “Create Account” etc. etc.
Love the idea of swagger documents auto-populated for externally created APIs. Once my modules are finalized, the next step would be to roll out external APIs once no changes are going to be made.
I’ve seen very little of this. But it is coming. It has too, as it is the only way most people’s vibed apps are going to step up a gear into something that can be production-ready.
And external APIs will be a key part of it, as our apps become mere individual components in a bigger agentic ecosystem.
What I noticed was that Replit had already created the “APIs” but they were internal only. I guess technically any action like create contact, or anything that does something within the app is an internal API. I then asked agent to give me a list of all of the potential APIs in the app that could be exposed - it gave me a list of over ten potential things that could be used. This was a very simple app for testing adding contacts and getting a list of contacts. I never thought I would be building an app and creating APIs within it then calling them externally - Replit continues to amaze me!
Agree with this ending statement - there’s no reason in a world where replit exists not to create different abstraction areas and layers where you are working from an enterprise architecture mindset vs. a popstar app that has a very limited set of functions and experiences.
at you OAuth)