First of all, thank you for trying the product and sharing your feedback. I appreciate it.
While you can modify the source code to remove the watermark, you can also upgrade to the paid edition which helps keep the project sustainable. :) Additionally, you don't have to put in additional effort in keeping the fork up to date with our main repo.
I understand that our choice of single Docker container for hosting Appsmith may be counter-intuitive. We took that route because we were seeing lots of developers struggle with k8s (especially with multiple pods). That's why we actually simplified the experience to optimize for quick starts.
I look forward to your feedback and support for a growing open source project :)
I wish you the best, you have a great product already.
e.g. a count down field which count down seconds to zero OR a list display with automatically updates from the source
(Ironically, i will happily spend time build a custom back end source, if AS will take care of front end)
BTW, playing with appsmith right now, it crushed and is now down for more than 15 minutes
To answer your first question; yes, it's possible to build dynamic apps that can countdown the seconds to zero or build a timer dynamically. The sample application: https://app.appsmith.com/app/input-widget/input-counter-reva... shows a counter. In this example, while a user is required to click a button, this can be modified to be triggered automatically every 1 sec.
It's currently not possible to power the UI via websockets yet. This is an open feature request that we are yet to implement.
Having said that, I'm sorry that Appsmith crashed for you. Were you trying us out on Appsmith Cloud (https://app.appsmith.com) or were you self-hosting Appsmith via Docker/k8s?
Please feel free to email me at arpit [at] appsmith.com & we'll help you out succeed with the product.
Started some of the templates on the cloud - crushed for more than 10 minutes
Right now, very slow. Multi-second latency with smartlook.cloud and iam-something....
Best of luck!!!
Good luck. Hope this helps.
Got a question: is it possible to operate without something like docker, on Windows? The place I would like to deploy it is a VM, and nested VMs are not a good option with what I have available.
As I read the Apache license, you are allowed to modify the code, but I see nothing to compel you to distribute the modification.
Agreed on the all in one docker solution, it seems like a choice made to get things off the ground, not one predisposed to effective prod operations (storage being the major headache, though I assume there's not too much stored on disk).
Regarding the more complex application, do you think you could pinpoint what quality caused the low-code version to be too complex?
To be fair, I have yet to see a single helm chart that was not a mess. Messiness is endemic to the file format (YAML) and templater (text based). Further, there are no enforced standards defining how to format ingress, service, etc configuration keys in values.yaml so every chart developer is on their own.
The appsmith helm chart works out of the box, which is better than many.
My main issue is to put everything in the same stateful pod using supervisord. It doesn’t scale, I don’t want to use supervisord inside a kubernetes pod, it’s huge and slow to get ready. The helm chart does also weird things such as having a namespace définition or an autoupdate by default.
It has been successful, but I recently had to patch it to remove a new annoying «made with appsmith» ad on our applications that can only be disabled on the enterprise edition or if you edit the source code of the open source one and are willing to share your patch of course. Another important planned feature, SAML/OpenID has also recently been announced to be only for the not open source enterprise edition. Their Kubernetes helm chart is a mess too. They want to be noob friendly with everything in a single stateful container. I understand the reasons, but I don’t like it.
On the good parts, we build applications in a few days, and it’s great for prototyping and simple applications. One large application we build has reached the limits of no-code platforms, in our opinion. It will be rewritten in code, but we think it was not a waste of time and resources as we could iterate fast, and we didn’t know whether a more expensive development would be worth it.