[HN Gopher] Show HN: Strada - Cloud IDE for Connecting SaaS APIs
___________________________________________________________________
Show HN: Strada - Cloud IDE for Connecting SaaS APIs
Hi HN! I'm Arash, one of the founders of Strada
(https://www.getstrada.com), a cloud IDE for building automation
workflows across your company's SaaS apps. Strada handles
integrations, triggers, infrastructure and observability while
letting you write core workflow logic in Python (more languages
soon). It's for teams that hit limitations with low-code tools
while building with internal apps -- eg. Zendesk, Jira, Salesforce,
Slack. You can access our docs at (https://docs.getstrada.com).
While working on our first product (a unified accounting API), we
learned that as companies grow, their integration teams become more
technical but typically still use low-code tools. We also observed
that as LLMs are becoming popular, these teams (usually outside of
engineering) are adopting more code. For example, we spoke with
multiple companies that generate integration code with an LLM and
use it in their low-code platform. Unfortunately, most integration
tools are not designed with code as a first-class citizen. They
often have limited support for external libraries, restrict how
variables are used, and limit how code blocks interact with other
workflow steps. But integration developers put up with them because
stitching together authentication, scripts, APIs, infrastructure,
and observability is time consuming and not a core focus for their
teams. Instead of drag-and-drop blocks, we chose code as the main
interface. Tasks that are frustrating in low-code tools become
simple with code: conditional logic with layers of branching,
complex transformations, or problems that an external library
already solves (for example, redacting personally identifiable
information with the scrubadub library [1]). Each Strada workflow
is a contiguous Python script, and every action configured in the
UI can be invoked like a function. We started with Python since
it's popular with teams outside of engineering, like IT, Data, and
Ops. Our goal is to help integration builders focus on logic
unique to their business by simplifying everything outside of that:
- Integrations: we handle authentication and provide abstractions
for common app actions; - Triggers: workflows can be triggered by a
webhook or run on a schedule; - Infrastructure: one-click
deployment with automatic scaling; - Observability: detailed
logging of workflow actions, payloads, and errors. Today,
customers use Strada for workflows like Customer Support (receive
Zendesk ticket webhook, remove sensitive information, perform
sentiment analysis using OpenAI, and escalate problematic tickets)
and Customer Onboarding (receive webhook with new customer data &
files, transform to expected format, send request to third-party
API, send request to internal endpoint). What we're currently
working on: - More enterprise app integrations; - A self-hosting
option; - More runtimes in addition to Python; - AI for code
generation. We're excited for you to try it and share your
feedback! [1] https://github.com/LeapBeyond/scrubadub
Author : arash-khazaei
Score : 55 points
Date : 2024-02-22 16:45 UTC (6 hours ago)
(HTM) web link (www.getstrada.com)
(TXT) w3m dump (www.getstrada.com)
| QuinnyPig wrote:
| I really like where you split the difference between "no code"
| and "you'd best be a decent developer to use this."
| yodon wrote:
| I've been waiting for someone to build this (or build what I
| think this is). A couple questions:
|
| Do you handle retry on failure and exponential backoff on rate
| limiting? (I'm hoping the answer to both of these is yes.)
|
| Do I have to worry about rate limiting my calls to your platform,
| and if so do I have to rate limit them at your rate limit or the
| 3rd party's rate limit or ? (I'm hoping the answer to this is
| within reason I don't have to worry about rate limits, you just
| queue up my calls and forward them at the right rate.)
|
| Is there a way inside the custom Python code to make an arbitrary
| 3rd party endpoint look idempotent to outside callers? (Hoping
| for this to be yes.)
| arash-khazaei wrote:
| 1. Currently, we expose the status of actions (success/failure
| boolean), plus any additional metadata (status code, any http
| response header) so that you can retry (that's the nice thing
| about it being fully in Python - an `if` or `for` loop is easy
| to write). We are working on allowing you to configure the
| retry mechanism within the action, so we handle it on your
| behalf. However, for now we didn't want to be too prescriptive
| on what should happen on failure.
|
| 2. You do not have to worry about rate limiting calls to our
| service. We enqueue each request and respond with a HTTP status
| `201`, and our worker cluster will start processing the job.
| Within the workflow, 3rd party API calls can be rate limited,
| but for now we leave that to the discretion of the workflow
| author (see 1.)
|
| 3. I may need a bit of clarification on this one. Is the
| question whether you can provide idempotency key when making a
| request to a 3rd party endpoint? If so, yes you can. We have
| simple abstractions of common actions (for example sending a
| message in slack, or creating contact). However, you can always
| build your own custom action that sits on top of the underlying
| HTTP request, and therefore you can pass any additional
| parameter (idempotency key) in this case.
| yodon wrote:
| This sounds great - very sensible answers for an early stage
| product.
|
| Re: your mention elsewhere of adding language support beyond
| Python, I'll call out C# (first choice) and/or Typescript
| (2nd choice) as my personal favorite votes.
| xwowsersx wrote:
| > Code as a first-class citizen > Write your workflows in Python,
| import any package, and version control with Git.
|
| I think this is the winning feature. The issue with Low-code/No-
| code, as many engineers acknowledge, is that they tend to be
| utilized for tasks better suited for coding. Companies are
| attracted to the notion that designers, PMs, or others can
| independently create tools and conserve engineering resources.
| However, these tools often exceed the capabilities of LC/NC,
| resulting in an unmanageable complexity. In reality, code proves
| effective for constructing large, intricate systems -- or at
| least has a fighting chance where LC/NC falls short. Anyways, all
| of this is to say that code as a first-class citizen + source
| control is a big win here.
| arash-khazaei wrote:
| Thanks - this was one of the main inspirations for building
| Strada! We had many conversations with integration developers
| and when we asked to see their workflows, we saw a lot of
| complexity in their low-code platforms that could have been
| made simpler with a more code-first approach.
|
| One particular conversation that stood out was a developer that
| had to chain 6 layers of low-code blocks, just to flatten a
| JSON response. In this case he wished that he could write a
| simple recursive function to solve the same task.
| joshmanders wrote:
| Some landing page nitpicks:
|
| - Your video opens up in 25% smaller window than the screenshot,
| which is weird, only way for me to really see whats going on in
| the video is by making it full screen, on a 27-inch 4k display
| where now it's just too large.
|
| - I don't know if you're just talking that fast or you sped up
| the video, but I had to for the first time in my life change the
| speed of a video to 0.75x just to understand what you were
| saying.
| arash-khazaei wrote:
| Thanks for the feedback!
|
| - We'll take look to address this.
|
| - We actually did slightly speed up the video. We will re-
| upload the video with the original speed. Thanks for calling
| this out!
| joshmanders wrote:
| It's a common thing I'm noticing about videos from technical
| people on their products. They're so intimately familiar with
| the product (obviously because they made it) that they just
| fly through everything because they just assume that the
| viewer already understands the product. We don't.
| arash-khazaei wrote:
| Very fair!
| rhinohornbill wrote:
| Love this idea. Good luck with everything!
| bdcravens wrote:
| Any worries naming it the same as https://strada.hotwired.dev/? I
| realize they aren't related problem spaces, but naming collisions
| still aren't ideal.
| arash-khazaei wrote:
| We've grown attached to "Strada", so for now no plans on
| changing.
|
| I do have friends/colleagues forward me the occasional DHH
| tweet from time to time, whenever he mentions Strada :)
| Soerensen wrote:
| This is super cool! I've often been frustrated with the lack of
| complexity that NC/LC solutions offer. Look forward to playing
| around with Strada!
| nathanwallace wrote:
| Readers may also enjoy Flowpipe [1], a cloud scripting engine to
| build workflow pipelines using HCL (like Terraform). It's as-
| code, self-hosted and open source. Our design choices were a bit
| different - focus on DevSecOps, composable OSS mods [2], first-
| class support for retries etc [3], and the flexibility to run
| function code or containers when required [4].
|
| 1 - https://github.com/turbot/flowpipe 2 -
| https://hub.flowpipe.io 3 - https://flowpipe.io/docs/flowpipe-
| hcl/step#retry 4 - https://flowpipe.io/docs/flowpipe-
| hcl/step/function
| klysm wrote:
| Every time I see something like this, my brain fills with all the
| difficulties of database replication and how it's almost
| certainly intractable to do with whatever half-baked API a SaaS
| tool has given you. It feels doomed and misguided
| rubenfiszel wrote:
| Look very similar to the script builder portion of
| https://github.com/windmill-labs/windmill, but not open-source,
| not self-hostable, without open-source integrations
| (https://hub.windmill.dev/) and without a workflow engine
|
| disclaimer: I'm founder of ^
___________________________________________________________________
(page generated 2024-02-22 23:01 UTC)