Live data from Hacker News

Launch HN: Paragon (YC W20) – Visually Build API Workflows

news.ycombinator.com

21–30 of 56 posts

Re: Launch HN: Paragon (YC W20) – Visually Build API Workflows

#24
Congrats on the launch, neat idea!

You guys have thoughts on automated testing? My experience with visual programming in the wild (zapier, iterable, mailchimp) is that you end up with a lot of orphan and broken "scripts" deployed only to the production environment by well-meaning operators who can't really test or maintain them. It's interesting that this is geared towards devs, but I worry that you'd have a bunch of the same problems as the system grows unless there's a good way to rig up functional/e2e/integration tests the way we usually with cypress, capybara, etc.

Seems like there must be a solution, but my first idea of just setting up a "test" environment that points to other test services seems really costly if it's running on every commit that gets pushes like we often do with CI.

Re: Launch HN: Paragon (YC W20) – Visually Build API Workflows

#28
Who are your audience here? I’m trying to figure out whether this is some Zapier/Integromat type of tool, but the emphasis on more “high volume” integrations and scenarios is interesting.

I’m personally just doing some simple workflows with Gitlab-to-Telegram etc, and I have to say that I find it quite difficult to accomplish that what I consider “medium complexity” stuff: one Gitlab push event has multiple commit messages, I want to iterate over them for formatting, and then collect all of them in a single Telegram message.

Unfortunately, the sheer fact that I’m not “allowed” to write any code makes the solution so much more complex; debugging what’s wrong is a nightmare, and generally it all just leaves a bad feeling behind.

Don’t get me wrong; I’m paying for this service because I get value out of it, but it feels as if the devil is in the details if you want to pull this off.

Re: Launch HN: Paragon (YC W20) – Visually Build API Workflows

#30
No Code / Low Code skeptic here.

I fail to see how using this GUI mixed with raw code approach would make my development workflow any faster.

For example, I've posted below a Node.js implementation of what you created in the YouTube demo linked in the OP, and it took me less time to write than it did for you to create the same "workflow" using the GUI in the video demo.

And the best part is I can run this JS code on my own server, or as a cloud function on AWS Lambda, etc. I retain complete control and avoid vendor lock in. And there is no way you and your team can compete with AWS on cloud function pricing. So where is the value for developers in your offer?

It seems like you are offering a managed compute service at a much higher price point than AWS, and then trying to justify that price point by tacking a GUI onto it. At best the GUI will be able to abstract away a little bit of boilerplate code, but inevitably the interface it exposes will not be as flexible, fully-featured, expressive, or IMO, as easy to reason about, as the interface exposed by any modern programming language.

const { Pool } = require('pg'); const pool = new Pool(); await pool.connect(); const accountSid = 'ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'; const authToken = 'your_auth_token'; const twilioclient = require('twilio')(accountSid, authToken); const sgMail = require('@sendgrid/mail'); sgMail.setApiKey(process.env.SENDGRID_API_KEY);

const res = await pool.query(`SELECT * FROM USERS WHERE "lastSeen" { let message = `Hi ${row.name}, we haven't seen you in a while`; if (row.phone) { twilioclient.messages.create({ body: message, from: '+15017122661', to: row.phone }) .then(message => console.log(message.sid)); } else { const msg = { to: row.email, from: 'test@example.com', subject: 'Come back', text: message, }; sgMail.send(msg) .then(() => {}, error => { console.error(error);

                if (error.response) {
                    console.error(error.response.body)
                }
            });
    }
}) await pool.end()
Post reply on HN