5 ms·

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 ea

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.)
    - keithwhor 7y ago
      This may be a little different than you expect: OAS didn’t meet our needs for defining serverless function schema semantics. We considered an open approach, but we then watched numerous small companies die trying to convince standards bodies to adopt their innovations. Like, raised money, convinced nobody, stagnated or died, and highly paid engineers at BigCos that were unintentionally unempathetic to the excitable new founders — whose dreams just evaporated in smoke — kept attending open spec design-by-committee meetings with little forward progress. So we decided to work directly with API companies — not standards bodies — and figure out how to deliver the right product(s) to solve real customer needs. That’s all there is to it. We stand on the shoulders of giants and we certainly love working with companies that adhere to existing standards — as mentioned, the things we’ve contributed are completely compatible! We don’t have an ego about our specifications, we just have a desire to deliver value and not die — and waste the most productive years of our lives — waiting on standards bodies.

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.)
  - keithwhor 7y ago
    This may be a little different than you expect: OAS didn’t meet our needs for defining serverless function schema semantics. We considered an open approach, but we then watched numerous small companies die trying to convince standards bodies to adopt their innovations. Like, raised money, convinced nobody, stagnated or died, and highly paid engineers at BigCos that were unintentionally unempathetic to the excitable new founders — whose dreams just evaporated in smoke — kept attending open spec design-by-committee meetings with little forward progress. So we decided to work directly with API companies — not standards bodies — and figure out how to deliver the right product(s) to solve real customer needs. That’s all there is to it. We stand on the shoulders of giants and we certainly love working with companies that adhere to existing standards — as mentioned, the things we’ve contributed are completely compatible! We don’t have an ego about our specifications, we just have a desire to deliver value and not die — and waste the most productive years of our lives — waiting on standards bodies.