Alternatives to UI Bakery

My company wants to make some relatively small, self-contained web apps to go through specific engineering analysis workflows.

Each app would involve:

(a) User inputs numbers and tabular data either in a table or from a csv import

(b) App makes plots of this data

(c) App performs calculations based on user input and outputs results as either plots or numbers or tabular data

It seems like there must be zillions of applications where people want these things, so I want a 'low code' approach that already handles a bunch of details so we don't have to. Experience in the past with Angular has involved, in my experience, a lot of low-level coding to 'reinvent the wheel', creating capabilities (like menus to control plotting options like font size) that I'd expect to be very common.

Specific wants:

(a) Plotting capabilities with prebuilt convenient plotting controls

(b) Ability to 'save' and 'load' (as in, you do the analysis and get results and want to save so that you can reopen this save environment with the data and analysis, as if you'd never closed it)

(c) For specific components, ability to swap out the built-in components with a customized plot/widget.

For example, with (c), we might have a situation where we do want to make a custom plot or tool, and would like to be able to drop that into the general application

Question is - does something exist that does what I am describing? What would you recommend? On our list to check out: Microsoft PowerApps , Dash , UI Bakery, Retool , Tibco Spotfire , Outsystems, Zoho, Creatio, or any other suggestions.

Other considerations:

(a) How easy are these apps to maintain (i.e., do they frequently make non back compatible, breaking updates, like they do with Angular)

(b) Need excellent security so I can deploy web apps for large companies

(c) General ease of use (would like to be efficient with developer time).

I'm standing up a web app that needs functionality, including profiles, directory, scheduling, video meeting, and payments.

I considered Wix, but I'm not sure it will meet these needs. I'm interested in no code / low code tools in order to move quickly but struggling to navigate through all the options. Any advice on how to select no code / low code tools like Webflow, Bubble, stackbit, Retool, BaseDash, Glide , airkit, adalo, stacker, unqork, tiled, airtable, zapier, v.one, candu, bravo studio, amazon honeycode, unstack, dittofi, makerpad, softr, appsheet, etc.?

Our whole DevOps stack consists of the following tools:

• GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
• Respectively Git as revision control system
• SourceTree as Git GUI
• Visual Studio Code as IDE
• CircleCI for continuous integration (automatize development process)
• Prettier / TSLint / ESLint as code linter
• SonarQube as quality gate
• Docker as container management (incl. Docker Compose for multi-container application management)
• VirtualBox for operating system simulation tests
• Kubernetes as cluster management for docker containers
• Heroku for deploying in test environments
• nginx as web server (preferably used as facade server in production environment)
• SSLMate (using OpenSSL) for certificate management
• Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
• PostgreSQL as preferred database system
• Redis as preferred in-memory database/store (great for caching)

The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

• Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
• Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
• Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
• Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
• Scalability: All-in-one framework for distributed systems.
• Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.

We chose AWS because, at the time, it was really the only cloud provider to choose from.

We tend to use their basic building blocks (EC2, ELB, Amazon S3, Amazon RDS) rather than vendor specific components like databases and queuing. We deliberately decided to do this to ensure we could provide multi-cloud support or potentially move to another cloud provider if the offering was better for our customers.

We’ve utilized c3.large nodes for both the Node.js deployment and then for the .NET Core deployment. Both sit as backends behind an nginx instance and are managed using scaling groups in Amazon EC2 sitting behind a standard AWS Elastic Load Balancing (ELB).

While we’re satisfied with AWS, we do review our decision each year and have looked at Azure and Google Cloud offerings.

#CloudHosting #WebServers #CloudStorage #LoadBalancerReverseProxy

When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

We've been happy with nginx as part of our stack. As an open source web application that folks install on-premise, the configuration system for the webserver is pretty important to us. I have a few complaints (e.g. the configuration syntax for conditionals is a pain), but overall we've found it pretty easy to build a configurable set of options (see link) for how to run Zulip on nginx, both directly and with a remote reverse proxy in front of it, with a minimum of code duplication.

Certainly I've been a lot happier with it than I was working with Apache HTTP Server in past projects.