Hacker Newsnew | past | comments | ask | show | jobs | submit | SvenAl's commentslogin

I had the same thing, they told me my account details changed on the day they changed. My business works with enterprises and yeah NET 30 to NET 90 days for payment terms, so this is a painful one to correct.

I actually reached out to Wise support and complained about this practice, as this is borderline illegal, a bank is not allowed to behave like this. They said they are doing an internal investigation on what happened and will get back to me within 30 days.

I'm also looking at filing a complaint to Consumer Financial Protection Bureau (CFPB) or similar.


(founder here) Webiny is an option I would recommend checking out. It's open-source, so unlike Webflow, you can actually creation your own low-code components. Webiny has a Page Builder, Form Builder, File Manager and a Headless CMS. All products can be configured and use as a low-code solutions.


I've been dealing with serverless since 2018 and have a company with a 100% serverless and open-source product (webiny.com). I'm not sure I fully agree with your 4 issues and the fact that Web Assembly is the answer.

"Serverless functions are slow" -> not really, only if designed poorly

"DX serverless functions is sub-par" -> where's your proof, again you'll have bad experience as a developer only if you don't know what you're doing. Which I see mainly from people trying to approach building serverless applications by having a container-like mindset and that leads them to bad design choices.

"Serverless functions come with vendor lock in" -> I think most of us are beyond the point of that vendor locking is bad choice. Worse choice is picking a sub-optimal technology with lower performance, higher cost and lesser reliability.

"Cost eventually gets in the way" -> Again, only if you don't know what you're doing and make bad design choices.

When it comes to Web Assembly, I don't see how this is a better choice of technology vs something like Node. In node I have a much wider support of the technology than WA (talk about vendor-locking), I have a proven eco system of libraries, knowledge and a much bigger talent pool to source from. The cold start issue you mentioned on your website, I can tell you first hand, the cold start is not really that big of a problem, not big enough that you would want to switch to a different technology and there are many ways to mitigate the cold start problem.

Just saying, I'm far from convinced that there is a benefit in switching. I would love to see more detailed benchmarks and examples I would be able to replicate than just statements in a blog post.


If you have Node apps running in Lambda and are happy with the architecture, cost, and operating model: great! You've done good work and/or are very lucky and there's no need for you to rip everything out and start over.

Heck, even if you're curious about WASM and want to try some experiments with (say) fast Rust crypto libraries or embedded database engines w/o the risk of flaky native code crashing your V8 runtime: again, you can just run WASM from a Node worker thread and keep cruisin'.

For those of us who _don't_ have a huge investment in Node, have hard requirements around e.g. memory usage, cold start times, or even just plain old _cost_ (which can become a major factor when you consider the AWS lock-in) that Lambda doesn't meet really benefit from another option.

Your good fortune in finding a stack that works well doesn't mean that folks who have different needs or constraints are dumb, ignorant, or lazy.

As an aside, I think you also might be underestimating the depth of experience and knowledge of the Fermyon crew when it comes to containers, cloud runtimes, and serverless development. This is substantially the same team that built Helm, and a lot of other Kubernetes and cloud-native ecosystem projects along the way.


I can believe the other points, but the WASM hype train has officially jumped the shark.


Hey there ... I've been building serverless applications since 4 years now and have gone through a steep learning curve while the technology was very young. I think today you can easily build scalable serverless services using Lambda and other offerings. There are nuances on how to avoid specific bottle necks and work around them, but you'll only spot them probably once they happen.

The database is one of the most important choices you can make. Any database that requires a TCP/IP connection and doesn't work with an HTTP API is out of the picture due to the way lambda functions work with such databases. See more: https://www.webiny.com/blog/using-aws-lambda-to-create-a-mon...

The learning curve for DynamoDB is steep, but nothing that a senior developer can't tackle in a few weeks. It's a worthy skill to have, especially if you work in the AWS ecosystem.

Vendor locking will always be there, but really, don't worry too much about it, especially in the beginning. There are ways to protect yourself by abstracting your business logic and having a layer between how the logic interacts with the underlying serverless service. Later if you do need to move, the move will still be a bit painful, but not as much.

Cold start is not a problem at all if your bundle is not overly big. If needed you can always have a few provisioned concurrency functions.

Cost, benchmarks and similar - checkout this page: https://www.webiny.com/docs/performance-and-load-benchmark/i...

Disclaimer: I'm one of the authors behind Webiny - enterprise serverless CMS. Happy to answer any additional questions. Hope this helps!


Looks great! Any plans to support workflows other than for app development?


We've heard from teams working on non-mobile platforms that they share a lot of these pain points.

There's also the reality that coordinating app releases often includes wrangling dependencies on backend services.

All of the above is definitely on our radar… stay tuned!


Interesting ... when I first wrote the "Our Philosophy" section I was guided by showing the reader the things that are guiding us in how we are building Webiny. Never thought of it as being a benefit, but I see what you mean. Thank you for your feedback, I'll give it more thought and see if we can push it out to the homepage somehow.


It's more of a benefit than features. Features too often don't answer the question:

Why should _I_ care?

The philosophy at least spoke to me as opposed to features being about you.


I see what you are saying, looking at our homepage, it's true, we talk feature-talk. We'll be addressing this.


Not to worry, you're not alone :)

You are, as you should be, in love with your product (read: a collection of features). You know the nooks & crannies.

Moi? I don't care. I'm selfish. We all are. I need to know what you are going to do for _me_. What pains of mine are you going to fix? Benefits is short for: Use our product and we'll make these pain - X, Y, and Z - disappear.

Make me believe in your magic :)


Amazing, thanks for this!


Thank you for the support! In case of any other questions, I'm happy to help.


Thanks for the feedback. I agree a demo would be more useful. We might provide a more comprehensive platform overview in a video format. Operating a hosted demo requires us to maintain it and manage it. People tend to post all sorts of things in those types of environments, and if it’s a shared install base, other users might see content that is not appropriate. We need to find a good balance here, it just something we haven’t had time to get around to. On the overview video - I’ll see what I can do, it’s a good suggestion, thank you!


You could do a periodic reset / relaunch of the app so the demo starts from a clean slate after few hours / days.

I understand you sell support / hosted package. If you say you can't support a demo install, that would send a wrong message.


It’s something we’ll definitely look at we just haven’t gotten to it yet. We thought of doing periodic resets, but that tends not to provide the best experience. We’re thinking of having per-user instances, forcing users to create an account, but then delete the accounts on a periodic basis. This way, rather than having a single shared account we believe would work better. It’s just there’s a lot of things on our roadmap and we didn’t think this one being so important. Clearly we were wrong.


For an alternate take, as a developer I really don't have a problem with downloading and running it myself. If I were seriously evaluating it, I would 1) have to do that anyway, and 2) a hosted demo wouldn't be sufficient.

Not offering the demo may be a problem for tourists who aren't seriously considering this, but probably not for parties that are in the process of looking for something like this for a real use case.


That was my starting point when I was thinking about this. However it seems there’s a lot of users who just don’t want to do that initial investment, so having a demo would potentially help in converting them.


What about resetting it every day and put a warning that others can also use the demo/mess up the CMS?

Thats kinda what I’m used to seeing anyway :)


Thats one possibility, sure. We'll evaluate the best approach when we get to setting it up. Thanks for your suggestion, appreciate it!


If you can't be bothered to provide a demo of your product why should I bother setting it up myself?


We found developers, who are our target audience, want to test the setup, as that's part of the product experience and they get to learn the stack and the requirements. We are an open-source product, we don't have a SaaS offering, so we don't have a way yet to spin up demos or trial accounts for every user. You can view the product in our overview video without installing it: https://www.youtube.com/watch?v=gOGJKHXntiU


We have this overview page for our roadmap: https://www.webiny.com/roadmap/ In case you are interested in a particular feature, I'm happy to help.

Regarding an integration between google sheets and our CMS, we don't offer one out of the box, but if you create a lambda function on Webiny that pulls data from your google sheet, you can use the GraphQL API to then sync the data into the CMS.


At the moment, the cost for a small site would pretty much be equal to the cost of the Elastisearch service, the only non-serverless component we have. At a minimum that would be ~$25/mo.

We're looking to add plugins for Elasticsearch so you can replace it with something like Algolia making the whole thing 100% serverless. In that case, the cost would be zero, as it would be 100% under the AWS free tier. Once the free tier expires, the cost would probably be in cents. Have a look at our performance benchmark reports, we've noted down the cost of each test in detail for each of the AWS services: https://docs.webiny.com/docs/webiny-overview/performance-ben...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: