Automated Api
Automatically build and maintain backend APIs
I've recently come to the conclusion that AutomatedApi may not on it's own be the product I truly wish to sell. While functional and powerful on it's own, I truly believe that it's most powerful application is as a tool for agencies to leverage in service of their customers. It could go big in a b2b environment but I don't see that it's ready for that in it's current form. And that's not something I wish to do on my own or that I can afford to offload.
What I do see is a huge opportunity to build a development shop around it. Access to the backend allows me some extra leverage that isn't available to customers that improves the value proposition for a contract development service.
So, while I'm not shutting this down, I suspect that Automated API might not get updates under it's own power, but in service of a new product I'm building.
So I'm announcing here for the first time in public, I am launching a new development service aimed at reducing business need for direct hire and contract employees. It's essentially Development as a Service and provides code, maintenance, hosting, and support on a subscription (ish) model.
The fact is, there aren't enough developers around to fill every job posting for every job out there. Especially when most companies are posting for much higher qualifications than may be strictly necessary. I couldn't count the number of job postings I've seen that could be boiled down to 'we need someone who can maintain some existing projects and to undertake new small projects as necessary'. And we all know that they eventually admit this by hiring someone less qualified than they hoped to get in over half of all cases.
It occurs to me that what they need isn't developERS it's developMENT. And for that, I strongly believe there are enough developers, but only if they're managed correctly.
I aim to start a new firm, leveraging contracts to provide impetus and funds to build new tools like AutomatedAPI to further speed the development flywheel and I'll be opening those doors late next week with a new business on IndieHackers.
Does this mean that AutomatedAPI.com is dead? Absolutely not. This is just a change in vision that places it in a new position, as the first sprocket on a development flywheel that will help me to guide and enable development on hundreds (or thousands) of interesting projects for customers, when my previous approach might have limited me to only double digits in my career.
Hope to help you all in the coming years. Cheers.
Just finished putting together the first of 4 or 5 demo apps and blog posts that I intend to publish before making the next feature updates for Automated API.
My intent is to show how easily the service can be integrated with, so I published without any major refinement on the demo.
Blog post is here
No pressure, I'm just happy to have something up and running.
-
1
Great strategy of demo projects based on your tool, I'm planning to do that too, more and more.
What I would advise, though, is write more for people who know nothing about your tool. While reading the article, it took a lot of time for me to understand what is the project you're creating, what exactly automated Api does and how it all comes together.
I've suffered from the same thing in the past - you're writing as an author of the tool, knowing it inside out, but whoever lands on your blog they will start from zero knowledge, probably. So add some screenshots in the very beginning - show the end result, what is the stack exactly, and only then go into step by step.
-
1
Thanks, Good feedback. I intend to make a few passes on my posts and will definitely keep that in mind. It is, at best, a work in progress and somewhat incomplete.
Lately, I do all my writing much like I do my software development...which is to say, I'd rather slam it out there and iterate than take forever to get something online. Chasing long tail on these, so I think I'm comfortable with that.
I'm actually planning to also screen cast these as full demonstrations to accompany most of those posts, and to share the source, though as the product develops some of the implementation will change.
-
1
Yes, screencasts are very effective, these days it's all about video demos, my demos on YouTube channel, however long, are the most viewed of all time.
But keep in mind, that, at least in my case:
Short demos of FEATURES are not that popular: https://www.youtube.com/watch?v=C9rr-_zWyBw
Long demos of WHOLE PROCESS FROM START TO FINISH skyrocket in views/likes: https://www.youtube.com/watch?v=Pi4u1xO8FOw(I use Camtasia as a software, by the way)
-
1
I love Camtasia, and hate simple feature demos.
I intend to go from nothing to fully functional on all of these.
-
-
-
Just found and fixed a bug. Users don't always communicate well (or at all in some cases), so building things on your own platform is a damn good way to find stuff you should have fixed weeks ago but only now had the chance to see.
Oh, and if you have to frame out code in your dogfooding efforts just to scaffold in your actual service calls, think about open sourcing or at least making those tools public. Just sayin.
-
2
Full Story also helps here to see how your users behave.
-
1
This. I have learned a lot with the help of Fullstory and hotjar.
-
-
1
For us, tools like Bugsnag help a lot (a lot of alternative bug trackers like Sentry or Rollbar) which have all the request details and help to reproduce the issue exactly. Of course, there are some 5-10% edge-case situations which are only on user's side and you never catch them.
Open sourcing and making it public only helps if you have enough people that would actually use them.
-
1
Bugsnag looks interesting, hadn't looked into that one previously. And definitely on point with the open sourcing note.
I'm actually putting this little library out there as much to help me as to maybe help other folks. I keep meaning to put something out there, but committing to doing so publicly is part of an effort to actually put it together for myself.
-
AutomatedAPI just experienced the first major update to services. Not only is it running and generating code, database, and hosted environments from data definitions, it is now doing so with support for more HTTP verbs, with more self descriptive models, and with simple better REST compliance. And with much better code quality to boot.
There was somewhat of a headache when I realized the platform I'm built on (Azure) actively prevents one thing I rather liked, but I was able to to find a workable compromise in a matter of minutes.
So, I'm sending out an update shortly to the 9 signups I've had (none paying yet), and going pedal to the metal on content creation and documentation so other devs can actually use it.
All in, I'm calling it a win.
And if anyone is interested, here's a link to a postman collection I put together for testing.
Well, I finally hit go on the site.
The whole pipeline is operational, it's rough, but functional and its at a good spot to leap into the fray with. So rough in fact, that as I write this I noticed an issue on the home page. All that's left now is to continue to make small improvements while I build a little documentation and do the hands on reaching out to folks on my list that I had planned.
If anyone is interested, registrations are open and it does not require payment to reserve a username. Fingers crossed that I haven't mucked that much up in the last couple days.
I have a free tier planned but while I work out some of the next several improvements I'm attempting to not flood the system with users.
Cheers
Well, it's been a rough ride, and a while since I updated.
But I'm here to report some huge progress!
I have finally, after significant struggle, managed to re-implement initial prototype functionality under a new and faster architecture.
My goal was to make API provisioning, code and deployment as easy as a few button clicks once you have an API spec to work with. My first iteration, while functional, was cost prohibitive to run and took a good chunk of time to actually deploy to a serviceable state. I have that cost down significantly with this architecture and have reduced the time-to-live for a fully functional API down to about a minute, which is reasonable given that this includes provisioning cloud resources for the APIs themselves, the code repositories, and the data backing for the APIs.
For those interested in how the sausage is made. This is built in azure with a web service hosted via docker. The code generated is stored in a mounted network drive, and client services are deployed to an on-fly-provisioned web service deployed automatically with a simple git push from the generator service. This is all so that I can confidently scale as required to save cost while still providing good response times as necessary. Still hiccups to work out, but I was able to completely avoid the cost of keeping a cloud VM running 24/7...a cringe-worthy option I absolutely needed to avoid.
This is all to say that I expect to have room for some early adopters sometime near the end of July or beginning of August. I can't tell you how excited I am to have this project finally rolling toward a release and real value generation for you all.
Updates forthcoming. Tally HO!
First off, I know it's been some time since Automated Api saw an update. I've been chewing on some changes that I think will make the product much better as I move into an alpha phase.
Second, ALPHA! February 2019 is dedicated 100% to the beginning of actual use by real live people with real live problems to solve and products to build.
Let me describe what exactly that means.
-
APIs will be generated from Open API specifications
-
Alpha users will be able to hit those APIs; put, post, get will all be available
-
Alpha users will have to write no implementation code and no database code
-
All of the above should be complete by the end of February
For this first batch there will be no user facing interface or business profiles. Mission number 1 is to test and expose the API generation pipeline so we can nail it down and get everything provisioned as necessary. This means that those selected will have personal communications with me, during which the OpenAPI specs (yaml or otherwise) will be exchanged and iterated on, and functional API endpoints exposed to the customer.
If you are at all interested, please feel free to respond accordingly. I'm extremely excited by this opportunity and this product and I would love to involve people for whom this could solve a problem.
Needed a week for a sanity check. It has helped me refocus tho, and I've settled on an actual deployment pathway to get this into production.
Just a matter of time, will be accepting accepting simple OpenAPI definitions manually from selected Alpha users before February is done.
Obviously that doesn't scale, but for the first several users/customers I'd like to babysit the APIs through the process so I can directly monitor the backend generation and resolve bugs in real time.
getting stoked
An interesting thing happened overnight. While this project's public facing pages have been up for a shorter time, interest in Automated API has outpaced Wallaby Vault by a fair bit. Nothing huge, but it's progressed at a pace that suggests I may need to push that schedule up in order to keep interest up and maximize conversion when it actually does go live for users.
Feeling really good about this.
This week I placed a new version of the site online to collect emails. It's dead simple but enough for now. The target early audience is technical in nature so less is more is kinda how I'm approaching it.
I have this week also landed on a decision to speed up the operation of this product after seeing some slowness in one area of the prototype that I'd been working on for the last 6 months. It should allow new services with data backends to be up and accessible within a few minutes even under heavier load.
This will take some rejiggering but I think I can make that work in somewhat short order. I'm excited to get this rolling out to beta users next month and stoked about the traction I'm getting around the web.
Just have to keep on truckin'.
Comment