Hi All,
In the first look at Activity Workspaces, I introduced the new way we are organizing the upcoming Wappler 8. Now I want to take you a little closer and show you Setup.
This is a development preview. The screenshots show work in progress, and Wappler 8 isn't available to try yet. We hope to launch the beta soon so you can try it for yourselves. I would love your feedback while we are shaping these workflows.
Over the years, Wappler has gained a lot of capabilities, and their settings have grown with them. You might configure one part of the project in Project Options, look elsewhere for a database connection, then go to Server Connect for its global settings.
If you work with those tools every day, you know your way around. But when you return to an older project, help someone with their setup or start working with another environment, you still have to remember where each piece lives and how it relates to the others.
With Setup, we are bringing that configuration together into one central workspace. The application's settings, database connections, Server Connect globals, targets and provider resources can be understood in the context of the same project.
That is one of the changes I have been particularly looking forward to sharing. I also want to show you an idea we are still shaping: the deployment pipeline. Your feedback on that part will be especially valuable.
The application's configuration has a visual home in Setup. Select an item when you want to explore its properties.
See how your project fits together
The central view shows the different parts of your application configuration and their relationships. You can see the application, its client-side framework and the backend configuration, then select the part you want to work with.
The Inspector on the right shows the relevant properties. The Library on the left follows the context, helping you find settings and resources that belong in the area you are working on.
I like how this makes configuration something you can explore. You can start with the overall project, follow its structure and then get into the details of a particular setting or connection.
It also gives us a much clearer place to bring related configuration together as Wappler grows. A project with several environments and services should still be understandable when you return to it after working on something else for a while.
For example, when you need to check a database connection, Setup is the place to configure it. You can then use Data to explore the database and work with its schema or queries. Likewise, you configure Server Connect's global settings and security providers in Setup, then use them while building your server actions in Build.
That gives configuration a consistent home. You can answer “How is this application set up?” without having to reconstruct the answer from several different panels.
Start with the project's source
The source location is part of this picture too. At the top of the application view, the Repository section identifies where the project comes from.
The project's source is part of its setup, alongside the application configuration.
You can work with a local project folder or with a working copy of a Git repository. That repository could be hosted on GitHub, GitLab, another Git service or your own server. The project remains your source, and the workspace should make that connection clear.
This is useful even when you work alone. You might have several local copies, a client project connected to their repository or a project you are preparing to put under version control. Knowing which source you are working with is a good starting point before changing its configuration.
Source and deployment are two different relationships to keep visible: the repository identifies the code you work on, while targets describe the environments where the application will run. Git has its own workspace for changes, branches and history, and I will cover those workflows in a later article.
Three different contexts, kept together
Across the top of Setup, you can see how the workspace is organized. There is a place for the project's settings, a group for its deployment targets and a group for providers.
The tabs make the context visible as you move between the project, a target and a provider.
Those distinctions matter. A framework choice belongs to the application. A staging address belongs to a particular environment. A server offered through a hosting provider is a resource that may be involved in delivering that application.
They are related, but you do not always want to work on all three at once. Setup gives them a shared home while allowing you to focus on the part you need. That is the same thinking behind Activity Workspaces, applied to configuration itself.
General settings for the project
The General tab is where the project-wide configuration comes together. This includes the application and framework choices, along with the backend's global settings and modules.
For example, a Server Connect application may have shared settings, database connections and security providers. In Setup, those pieces appear in the context of the application, and you can select an individual item to inspect its configuration.
Global settings and modules are grouped with the backend configuration they belong to.
When I say “global settings” here, I mean settings for this project. Your general Wappler preferences are a separate thing.
There is a useful distinction within the backend configuration too. Global settings control shared aspects of the application, while a configured module represents something you can refer to from your server actions, such as a database connection or a security provider. Seeing both in their context helps explain where a change belongs.
You do not have to read every property to understand the overall arrangement. The visual view gives you the structure first, then the selected item's properties let you go further when you need to. That balance between overview and detail is something we are paying a lot of attention to.
We have also kept the source close to the visual configuration. Setup has Design, Code and Split modes, so the underlying configuration can be part of the same working experience. That connection is important to us: visual tools should help you understand and work with your project files.
Your project's extensions, with updates on your schedule
The Extensions section is another important part of Setup. It gives you a view of the extensions enabled for this project, including the frameworks, App Connect components and Server Connect packages that provide its capabilities.
See the project's extensions, inspect their versions and capabilities, and review project-file updates from the same workspace.
Select an extension and you can see what it provides, its version and the packages it depends on. The Library gives you a place to discover additions, while the project view shows the selection you are actually working with. That makes it much easier to understand what belongs to this application.
I want you to have clear control over that selection and over the updates you bring into a project. Check project files lets you review proposed file changes and choose which ones to apply. You can inspect what will change before accepting an update, or leave it for later.
That choice matters because projects are at different stages. When you are actively developing a new application, you may want to try an updated component or take advantage of a new capability straight away. For an application already in production, you may prefer to keep the version you have tested until you have time to review and test the update properly.
The workflow I want to make comfortable is straightforward: see what the project uses, decide whether an update is useful now, try it in Development, and bring it through Staging and into Production when you are ready. Reviewing an available update should help you make that decision, rather than make it feel like a decision has already been made for you.
It also gives us a useful way to discuss extension management together. How do you currently handle updates in a production project? Do you review them as they arrive, collect them for a planned maintenance release or update only when you need a particular fix? I would like to hear what would make that process clearer for you.
Targets give each environment its place
Every project has a Development target. That is the starting point for building and running your application during development.
You can then add other targets as you need them. Staging gives you an environment for reviewing changes before release, and Production describes the live application. A small project might go from Development straight to Production; another might need several staging or deployment environments.
Those environments have things in common, but they also have differences that matter. A server address, a connection or a delivery setting can belong to one target rather than another.
Setup brings these contexts into their own tabs. In this example, Development is followed by the optional Staging and Production targets. Selecting one brings its configuration into focus, while General remains the home for the shared application settings.
A closer look at the server connection configured for our example's Staging target.
The distinction I want to make easier to follow is what belongs to the application itself and what belongs to a particular environment. You should be able to see the context of a setting while you work on it.
Imagine returning to a project to check where its staging version is published. You can start with the Staging tab, rather than first looking through all the general application choices. Or, if you are changing a shared backend setting, you can begin in General and keep the target-specific configuration separate in your mind.
I would be interested to hear how you currently make that distinction in your own projects. Some of you have a simple local-to-production setup, while others work with several environments, different servers and several applications at once. Those are useful examples for us to understand as we refine this experience.
For example, the Development database connection can point to your local database while Staging and Production use their own connections. Bringing those settings into Setup makes the context much easier to see as you work, rather than treating each connection as an unrelated piece of configuration.
Providers alongside your configuration
Providers have their own group in Setup as well. This gives the provider and its resources a place alongside the application and its deployment targets.
A first glimpse of how provider resources are organized in the new workspace.
For today, I want to show the organization and the relationship to the rest of Setup. Connecting accounts and working through specific provider operations deserve a more focused demonstration, which I will share as we get into those workflows.
It is also useful to distinguish the hosting providers shown here from a Server Connect security provider. The names are familiar, but they have different jobs: one belongs to your infrastructure, while the other is part of your application's authentication configuration.
The workspace boundaries matter here as well. Setup is where the configuration and resources come together. Deploy is the destination for the publishing workflow, and Monitor focuses on the running application and its output. I will come back to those connections in later articles, using a concrete example rather than asking you to imagine every step from a single screenshot.
The deployment pipeline: an idea I want your feedback on
There is another part of Setup that I want to open up for discussion now. We are designing a deployment pipeline that makes the steps involved in preparing and delivering an application visible in the workspace.
This part is still a proposal we are working through. The screenshot shows the structure we are exploring, and I would like your input on the steps it should support and how much control you need. It is a good example of why I wanted to start sharing these articles before the first public preview release.
The proposed pipeline separates preparing the application, choosing its destination, delivering it and checking the result.
Build & Pack
This stage is about preparing what you are going to deliver. Depending on the project, that might involve building or compiling assets, bundling files, optimizing output, creating an archive or building a container image.
In the Library you can see some of the kinds of steps we are considering, such as builders, compilers, generators, bundlers, minifiers, optimizers and packers. The idea is to let the preparation follow the needs of the project, with an ordered set of steps where that is useful.
A straightforward project should be able to keep this simple. For a more involved build, I would like you to be able to see what happens and in which order, rather than having important steps live only in a separate checklist.
Destination
Destination describes where the prepared application is going. This is where the pipeline connects with the target and the infrastructure you have configured.
The distinction becomes useful when you have several environments. The application's source can stay the same while Staging and Production have different destinations and configuration. I want the pipeline to make it clear which environment you are preparing to work with.
Delivery
Delivery is the process of getting the prepared application to that destination. It could involve transferring files, publishing a build or deploying an application image, depending on the workflow.
This is where your real-world examples will help a lot. Some of you have a fairly direct publishing process. Others have scripts to run, services to restart or database changes to coordinate. I would like to understand which of those steps you want to bring into Wappler and which should remain under your own control.
Verification
Verification asks a very practical question: how do you know the deployment worked?
For one project, checking that the application responds may be enough. Another may need a health endpoint, a few smoke tests or a custom check before you consider the release complete. We want to make room for those needs in the pipeline design.
We are also interested in what should happen when a check fails. Do you want to pause and inspect the result, retry a particular step or return to a previous release? Those are decisions I would like to discuss with you as we shape the workflow.
The ownership of the flow should stay clear: Setup defines the target and pipeline, Deploy runs the publishing workflow, and Monitor helps you follow the running application. The details of the pipeline and its execution are still being developed, so this is the right moment to tell us what would make it useful in your projects.
Back to building, and over to you
Once you have worked through your configuration, Continue to Build takes you back to the authoring workspace.
That is the flow we want to make feel natural: understand how the project is set up, make the relevant choices, and get on with building the application. Setup remains there when you need to return to a setting, inspect a connection or work on a target.
This is one of the parts of Wappler 8 I have been looking forward to sharing. A lot of work goes into bringing these details together, and seeing the workspace take shape makes me excited about what we can build on top of it.
I would love to hear about three things:
- Which settings do you currently have to hunt for or switch panels to configure? Database connections, Server Connect globals and target settings are good examples, but tell me what gets in your way.
- What does your path from Development to release look like? Do you go straight to Production, use Staging or manage several destinations? Which settings should be shared, and which should vary?
- What do you do before or after publishing that the proposed pipeline should support? A short list of your actual steps would be especially useful, including anything you currently do outside Wappler.
For the deployment pipeline, which areas would make the biggest difference to your work? Choose up to two, and use the replies for anything missing.
- Build, bundle and optimize application assets
- Package or build container images
- Configure delivery to different destinations
- Coordinate database changes and custom scripts
- Check the application after deployment
- Recover from a failed release
Your examples will help us turn this into a workflow that fits the applications you actually build. Thanks again for all the feedback and ideas you continue to share with us.
