Not currently as far as I know, but my understanding is that it is in their roadmap? I'm not affiliated with them in any way, so not really sure... I only know what I've seen on their website.
This comes across as uninformed at best and ignorant at worst. Python still doesn't have a reliable way to handle native dependencies across different platforms. pip and setuptools cannot be the end all be all of this packaging ecosystem nor should they be.
I love Python, the ZEN of it, and you really need to accept the fact that there are conventions - quite a lot and that bash or shell scripts are where the magic happens, like environmental variables, if you know how to secure your app.
Even the self thing finally makes sense after years of bewilderment (“Wait: not even Java is that brutal to its users.”)
Lately stumbled over poetry after really getting the gist out of venv and pip.
Still hesitant, because Windows doesn’t play a role.
> Structurally, it's closer to a slasher/horror flick
Having rewatched T1 very recently, I couldn't agree more with this. At one point I turned to my partner and asked what genre this actually was because all things pointed to horror.
Hoosiers, for sure. "My team is on the floor" was such a flex as a coach, it is still difficult for me to separate the man he played in that movie and the actor, to me they're one and the same.
First, nice work. I'm certainly glad to see such a tool in this space right now. Besides a UI, what does this provide that something like Browserless doesn't?
Thanks! Wasn't familiar with Browserless but took a quick look. It seems they're very focused on the scraping use case. We're more focused on the agent use case. One of our first customers turned us on to this - they wanted to build an RPA automation to push data to a cloud EHR. The problem was it ran as a single page application with no URL routing, and had an extremely complex API for their backend that was difficult to reverse engineer. So automating the browser was the best way to integrate.
If you're trying to build an agent for a long-running job like that, you run into different problems:
- Failures are magnified as a workflow has multiple upstream dependencies and most scraping jobs don't.
- You have to account for different auth schemes (Oauth, password, magic link, etc)
- You have to implement token refresh logic for when sessions expire, unless you want to manually login several times per day
We don't have most of these features yet, but it's where we plan to focus.
And finally, we've licensed Finic under Apache 2.0 whereas Browserless is only available under a commercial license.
Sounds like a prooblem that can be solved with a Playwright script with a bit of error checking in it.
I think this needs more elaboration on what the Finic wrapper is adding to stock Playwright that can't just be achieved through more effective use of stock Playwright.
I recently implemented something for a use case similar to what they described. To make something like that work robustly is actually quite a bit more effort than playwright script with a bit of error checking. I have not tried the product, but if it does what it claims on back of the box it would be quite valuable if for nothing more than the time savings of figuring it all out on your own.
Prefect has more polish and is easier to get started than any of the existing options. We've been running their self-hosted for over three years and it basically stays out of the way.
We looked at Dagster as well as Airflow. I really, really liked Dagster but the BI team didn't.
I cannot imagine using Airflow for anything meaningful and respecting myself at the end of a work day. The local development experience was abysmal. Deployments sucked.
That being said, if you're not using anything except maybe cron right now, and if you don't care about the solution being a proper data pipelines orchestration platform trademark symbol, I'd recommend starting with Windmill.
Thanks! We're similar to Twingate in how we model resources, but our policy system has optional conditions you can apply to restrict access further, which works a bit differently. We expect to continue building in that area over time. We also use WireGuard as a transport while I believe Twingate operates over QUIC.
My understanding is that Twingate uses a service-based access model, rather than host/IP/ACL-based, as Wireguard defines the world.
As you are based on WG, have you somehow paperer over that to move away from network trust and lack of scalability (that I read across HN/Reddit/YT) inherent to other WG based solutions?
I may not be fully understanding the question, but I think you may be referring to DNS-based resources? Those will allow you to manage access to an app or service by its DNS name (wildcards supported). You can also use IP or CIDR resources as well of course.
In terms of scalability, are you referring to throughput or simply the complexity of policy management as the number of resources grows?
I refer to doing service based connections, abstracted away from whether its DNS, IP or something else. To do this you really need a private DNS function and to operate with attribute based access controls.
Complexity of policy mngt. I read that ACLs are fine at small scale but become a nightmare at larger enterprise scale.
Firezone's DNS-based routing is able to manage access to multiple services independently, even if they share the same IP address. So you could for example allow access to gitlab.company.com but not jira.company.com even if they were on the same webserver / loadbalancer.
It took a couple iterations to get it right - lots of fun edge cases involved. We ended up having to build automatic NAT64 and 46 for DNS resources to handle some of them. We wrote a post on how this works: https://www.firezone.dev/blog/how-dns-works-in-firezone
One man's trash is another man's serious