5 ms·

It's just JavaScript. It's absolutely portable. The APIs that run atop us use the Standard Library registry, you can think of it like a package manager / proxy

It's just JavaScript. It's absolutely portable. The APIs that run atop us use the Standard Library registry, you can think of it like a package manager / proxy of sorts. But if all you're doing is writing logic to connect things, you could conceivably host it on your own after you prototype with us -- you'll just lose some of the goodies we provide like automatic webhook signing. Also, our gateway / schema specification is open source and portable as well: https://github.com/FunctionScript/FunctionScript https://github.com/FunctionScript/FunctionScript

eropple 7y ago
Why should somebody use this instead of OpenAPI?
- keithwhor 7y ago
  They’re compatible. FunctionScript is just a system for easily adding schemas to JavaScript functions inline. We needed to write a specification that made it easy for people to build Serverless HTTP endpoints strictly from within JS.
  - eropple 7y ago
    That's not an answer, though. Why should somebody use any of this over an OpenAPI specification? I'm biased, as I've written two web frameworks that both generate OpenAPI documentation trivially and inline (for Ruby[0] and for NodeJS[1]), but I've looked pretty deeply into the project you're offering here and I'm not seeing the value over existing, open, collaborative solutions. I have a strong interest in APIs being very good and very accessible (as those links hopefully demonstrate), but I also have a very strong interest in APIs not being intermediated unnecessarily. What does any of this do that can't be effectively done with current, broadly accepted technologies? Put another way, and forgive the bluntness: why should people give your company a vig for this? [0] - https://github.com/modern-project/modern-ruby https://github.com/modern-project/modern-ruby [1] - https://github.com/eropple/nestjs-openapi3 https://github.com/eropple/nestjs-openapi3
    - keithwhor 7y ago
      Congrats on all your hard work! Those are some impressive libraries. I come from an OSS background, it’s what started all of this, so I appreciate the hustle and contributions! The project that spawned all of this was a Node.js framework for easily building APIs that went viral here four years ago [0]. If it helps clarify, Autocode is for people looking to solve integration problems (A to B) for businesses easily. We can talk all day about which specification we use, but that argument is adjacent to the fact that the combination of tools we offer are faster by one — if not two — orders of magnitude at just delivering business value — a finished software product that connects A to B (to C to D). We’ve spent years of work developing this tooling and thousands of hours talking directly to both API companies and end-users about what they need. This is the result, and we’ve worked at making sure the tools we use — even if bespoke — are open source for others to learn from [1]. P.S. If this is your jam, reach out! We are hiring :) [0] https://github.com/keithwhor/nodal https://github.com/keithwhor/nodal [1.0] https://github.com/FunctionScript https://github.com/FunctionScript [1.1] https://github.com/stdlib https://github.com/stdlib
      - eropple 7y ago
        Thanks for the kind words. I don't drop those links to brag or troll for compliments, to be clear--more to establish bona fides. I've spent a lot of time building stuff for an open and interconnected web. I think you should be, too. But it looks like you aren't, and that sure seems like a real bummer. I get that it's both unsexy and probably a little uncomfortable, but the thing is, the demand for control that you're expressing here by going against open and collaborative standards really and truly does matter. Like--fundamentally and inescapably, the messaging I'm getting from you is "it's 'open source' but we demand to own it." Why do you need to own the specification to do what you do? What is OpenAPI stopping you from doing? Did you try to work with the OAS folks to improve it to enable whatever (if anything) can't be expressed? Did you evaluate stuff like vendor extensions to it to express those things? I get that the core of your Standard Library is open-source--but "open source" and "community collaboration" are pretty far apart. I understand the process for OpenAPI's evolution and change over time. What's yours? Whose commits get in? Who decides? I realize that the likely answers to these questions are trivial in the power-politics/realpolitik sense. Which is why my hackles are up, TBH. Not playing in the sandbox with all the other kids is a clear indication that you have it in you, whether you are or not right this second, to raise barriers to entry against anyone else who'd consider doing something with your tech. And that leads to a fragmentation ("welp, we'll have to fork") that this space well and truly doesn't need. If this was using standard tools and standard approaches--which all totally work with this, by the way, I've written a simpler but spiritually similar thing just by using openapi-js to dynamically generate clients--I'd be cheering you on. As-is? This sure looks like pissing in a community pool for your own benefit. How am I wrong? (Because, to be clear: I'd love to be. Stuff like this is important.)

eropple 7y ago

Why should somebody use this instead of OpenAPI?

keithwhor 7y ago
They’re compatible. FunctionScript is just a system for easily adding schemas to JavaScript functions inline. We needed to write a specification that made it easy for people to build Serverless HTTP endpoints strictly from within JS.
- eropple 7y ago
  That's not an answer, though. Why should somebody use any of this over an OpenAPI specification? I'm biased, as I've written two web frameworks that both generate OpenAPI documentation trivially and inline (for Ruby[0] and for NodeJS[1]), but I've looked pretty deeply into the project you're offering here and I'm not seeing the value over existing, open, collaborative solutions. I have a strong interest in APIs being very good and very accessible (as those links hopefully demonstrate), but I also have a very strong interest in APIs not being intermediated unnecessarily. What does any of this do that can't be effectively done with current, broadly accepted technologies? Put another way, and forgive the bluntness: why should people give your company a vig for this? [0] - https://github.com/modern-project/modern-ruby https://github.com/modern-project/modern-ruby [1] - https://github.com/eropple/nestjs-openapi3 https://github.com/eropple/nestjs-openapi3
  - keithwhor 7y ago
    Congrats on all your hard work! Those are some impressive libraries. I come from an OSS background, it’s what started all of this, so I appreciate the hustle and contributions! The project that spawned all of this was a Node.js framework for easily building APIs that went viral here four years ago [0]. If it helps clarify, Autocode is for people looking to solve integration problems (A to B) for businesses easily. We can talk all day about which specification we use, but that argument is adjacent to the fact that the combination of tools we offer are faster by one — if not two — orders of magnitude at just delivering business value — a finished software product that connects A to B (to C to D). We’ve spent years of work developing this tooling and thousands of hours talking directly to both API companies and end-users about what they need. This is the result, and we’ve worked at making sure the tools we use — even if bespoke — are open source for others to learn from [1]. P.S. If this is your jam, reach out! We are hiring :) [0] https://github.com/keithwhor/nodal https://github.com/keithwhor/nodal [1.0] https://github.com/FunctionScript https://github.com/FunctionScript [1.1] https://github.com/stdlib https://github.com/stdlib
    - eropple 7y ago
      Thanks for the kind words. I don't drop those links to brag or troll for compliments, to be clear--more to establish bona fides. I've spent a lot of time building stuff for an open and interconnected web. I think you should be, too. But it looks like you aren't, and that sure seems like a real bummer. I get that it's both unsexy and probably a little uncomfortable, but the thing is, the demand for control that you're expressing here by going against open and collaborative standards really and truly does matter. Like--fundamentally and inescapably, the messaging I'm getting from you is "it's 'open source' but we demand to own it." Why do you need to own the specification to do what you do? What is OpenAPI stopping you from doing? Did you try to work with the OAS folks to improve it to enable whatever (if anything) can't be expressed? Did you evaluate stuff like vendor extensions to it to express those things? I get that the core of your Standard Library is open-source--but "open source" and "community collaboration" are pretty far apart. I understand the process for OpenAPI's evolution and change over time. What's yours? Whose commits get in? Who decides? I realize that the likely answers to these questions are trivial in the power-politics/realpolitik sense. Which is why my hackles are up, TBH. Not playing in the sandbox with all the other kids is a clear indication that you have it in you, whether you are or not right this second, to raise barriers to entry against anyone else who'd consider doing something with your tech. And that leads to a fragmentation ("welp, we'll have to fork") that this space well and truly doesn't need. If this was using standard tools and standard approaches--which all totally work with this, by the way, I've written a simpler but spiritually similar thing just by using openapi-js to dynamically generate clients--I'd be cheering you on. As-is? This sure looks like pissing in a community pool for your own benefit. How am I wrong? (Because, to be clear: I'd love to be. Stuff like this is important.)