changes

sakshiarora386 · sakshiarora386 · commit 7151dc239dac · 2025-08-26T15:11:26.000+05:30
diff --git a/docs/microservices-framework/CLI.md b/docs/microservices-framework/CLI.md
@@ -36,7 +36,7 @@ Commands:
   clean                           clean the previous build.
   preview                         run the build in a hosted environment like production or development.
   gen-crud-api                    scans your prisma datasources and generate
-                                  CRUD APIs events and workflows
+                                  CRUD APIs events and event-handler functions
   plugin add                      installs eventsource and datasource plugins for godspeed.           
   plugin remove                   uninstalls eventsource and datasource plugins for godspeed.  
   plugin update                   update  eventsource and datasource plugins  
@@ -342,4 +342,4 @@ godspeed gen-graphql-schema
 ```
 > 📌 Prerequisite: must have installed graphQL plugin.
 
-Generates a GraphQL schema automatically from your existing Godspeed events and workflows.
+Generates a GraphQL schema automatically from your existing Godspeed events and functions.
diff --git a/docs/microservices-framework/config-and-mappings/config.md b/docs/microservices-framework/config-and-mappings/config.md
@@ -30,7 +30,7 @@ Environment variables in Godspeed are essential for securely managing configurat
 Environment variables can be set up using: 
 1. **Define variables** in `config/custom-environment-variables.yaml`.
 2. **Set values** in `.env` or use `export` in the terminal.
-3. **Access variables** using `<% config.variable_path %>` in yaml and `ctx.config` in typeScript workflows.
+3. **Access variables** using `<% config.variable_path %>` in yaml and `ctx.config` in typeScript functions.
 
 ### Step 1: Define Environment Variables in YAML Configuration
 
@@ -120,7 +120,7 @@ Once environment variables are set up, they can be accessed in Godspeed Project
   ```
   
 - **In TypeScript/JavaScript files**:
-  Use `ctx.config` to access values within your TypeScript workflows.
+  Use `ctx.config` to access values within your TypeScript functions.
 
   **Example TypeScript function**:
   ```typescript
diff --git a/docs/microservices-framework/config-and-mappings/env.md b/docs/microservices-framework/config-and-mappings/env.md
@@ -10,7 +10,7 @@ Using this file offers several advantages:
 
 - **Security:** Sensitive information (like API keys and secrets) is stored outside of the codebase, helping prevent accidental exposure.
 - **Environment-Based Configuration:** You can specify different values for variables based on your environment, allowing seamless transitions between development, testing, and production.
-- **Easy Access Across the Project:** The variables defined in .env can be accessed easily in Godspeed configurations, workflows, and scripts.
+- **Easy Access Across the Project:** The variables defined in .env can be accessed easily in Godspeed configurations, functions and scripts.
 
 .env file is placed in the root directory of your project.
 ```
diff --git a/docs/microservices-framework/databases/CokroachDB.md b/docs/microservices-framework/databases/CokroachDB.md
@@ -75,4 +75,4 @@ godspeed gen-crud-api
 ```
 * This command will generate the crud apis based on the sample prisma schema provided at ./src/datasources/cockroachDB.prisma
 
-* Now you can view the event and workflows according to the defined prisma schema
+* Now you can view the event and functions according to the defined prisma schema
diff --git a/docs/microservices-framework/databases/MariaDB.md b/docs/microservices-framework/databases/MariaDB.md
@@ -73,4 +73,4 @@ godspeed gen-crud-api
 ```
 * This command will generate the crud apis based on the sample prisma schema provided at ./src/datasources/mariaDB.prisma
 
-* Now you can view the event and workflows according to the defined prisma schema
+* Now you can view the event and functions according to the defined prisma schema
diff --git a/docs/microservices-framework/databases/MySQL.md b/docs/microservices-framework/databases/MySQL.md
@@ -91,4 +91,4 @@ godspeed gen-crud-api
 ```
 * This command will generate the crud apis based on the sample prisma schema provided at ./src/datasources/mysql.prisma
 
-* Now you can view the event and workflows according to the defined prisma schema
+* Now you can view the event and functions according to the defined prisma schema
diff --git a/docs/microservices-framework/databases/Overview.md b/docs/microservices-framework/databases/Overview.md
@@ -6,7 +6,7 @@ keywords: [database integration, prisma orm, schema driven development, postgres
 
 # Database Support Overview
 
-The framework takes the approach of schema driven development. It supports multiple kinds of SQL and NoSQL databases. The developer only needs to specify or generate the schema for a database, with authorization policies. The CRUD events and workflows are automatically generated from the schema itself.
+The framework takes the approach of schema driven development. It supports multiple kinds of SQL and NoSQL databases. The developer only needs to specify or generate the schema for a database, with authorization policies. The CRUD events and functions are automatically generated from the schema itself.
 
 The framework provides functionality to access almost all popular databases through Prisma-as-datastore plugin [Plugin Repository](https://github.com/godspeedsystems/gs-plugins/tree/main/plugins/prisma-as-datastore) which is a powerful tool for efficient and secure database interactions in web applications. 
  
diff --git a/docs/microservices-framework/databases/PlanetScale.md b/docs/microservices-framework/databases/PlanetScale.md
@@ -76,4 +76,4 @@ godspeed gen-crud-api
 ```
 * This command will generate the crud apis based on the sample prisma schema provided at ./src/datasources/planetscale.prisma
 
-* Now you can view the event and workflows according to the defined prisma schema
+* Now you can view the event and functions according to the defined prisma schema
diff --git a/docs/microservices-framework/databases/PostgreSQL.md b/docs/microservices-framework/databases/PostgreSQL.md
@@ -89,4 +89,4 @@ godspeed gen-crud-api
 ```
 * This command will generate the crud apis based on the sample prisma schema provided at ./src/datasources/Postgres.prisma
 
-* Now you can view the event and workflows according to the defined prisma schema
+* Now you can view the event and functions according to the defined prisma schema
diff --git a/docs/microservices-framework/databases/SQLServer.md b/docs/microservices-framework/databases/SQLServer.md
@@ -81,4 +81,4 @@ godspeed gen-crud-api
 ```
 * This command will generate the crud apis based on the sample prisma schema provided at ./src/datasources/mysql.prisma
 
-* Now you can view the event and workflows according to the defined prisma schema
+* Now you can view the event and functions according to the defined prisma schema
diff --git a/docs/microservices-framework/datasources/datasource-plugins/ChatGPT datasource.md b/docs/microservices-framework/datasources/datasource-plugins/ChatGPT datasource.md
@@ -3,7 +3,7 @@ title: ChatGPT Datasource Plugin
 ---
 **[Link to Plugin Source Code](https://github.com/godspeedsystems/gs-plugins/tree/main/plugins/chatgpt-as-datasource)**
 
-The ChatGPT plugin for Godspeed allows seamless integration with OpenAI’s language models, enabling dynamic AI-driven responses in your workflows and APIs.
+The ChatGPT plugin for Godspeed allows seamless integration with OpenAI’s language models, enabling dynamic AI-driven responses in your APIs.
 
 ### 1. Install the Plugin
 
diff --git a/docs/microservices-framework/event-sources/event-source-plugins/express-plugin.md b/docs/microservices-framework/event-sources/event-source-plugins/express-plugin.md
@@ -15,7 +15,7 @@ The Godspeed Express Plugin provides the following benefits:
 
 3. **Customizable Configuration:** The plugin allows for easy configuration of Express settings, such as port, request body limits, file size limits, JWT authentication, authorization, swagger generation etc.
 
-4. **Reusable pure function handlers:** The plugin works seamlessly with the Godspeed Core library, enabling the processing of cloud events in pure workflows, decoupled with Express API, making them reusable.
+4. **Reusable pure function handlers:** The plugin works seamlessly with the Godspeed Core library, enabling the processing of cloud events in pure functions, decoupled with Express API, making them reusable.
 
 5. **File upload feature:** The Express plugin allows you to upload files as well.
 
diff --git a/docs/microservices-framework/event-sources/event-types/http-events.md b/docs/microservices-framework/event-sources/event-types/http-events.md
@@ -46,9 +46,9 @@ http.post./mongo/user/search/{id}: #This is the only thing that changes across a
 
 - The event's first line comprises three key elements: the type of eventsource (e.g., `http`), the method (e.g., `put`), and the URL (`/mongo/user/{id}`). This format is defined by the eventsource plugin, and it is the only line that changes across all events.
 
-#### Accessing Event Properties in Workflows
+#### Accessing Event Properties in functions
 
-For an HTTP event, the headers, query, params and body data are captured in a standard format, and made available in the `inputs` object [for use in the workflows](/docs/microservices-framework/workflows/overview.md).
+For an HTTP event, the headers, query, params and body data are captured in a standard format, and made available in the `inputs` object [for use in the functions](/docs/microservices-framework/functions/overview.md).
 
 The inputs (event) object has following properties:
 If you have jwt authentication like strategy implemented, then
@@ -97,7 +97,7 @@ Framework will give you below folder structure.
 
 2. `/` is the default endpoint,if you want to provide your custom swagger endpoint, you can modify the endpoint from **"./src/eventsources/http.yaml"**
 
-#### Update http.yaml( src/eventsources/http.yaml )
+#### Update http.yaml (src/eventsources/http.yaml)
 
 ```yaml
 type: express
diff --git a/docs/microservices-framework/functions/native-language-functions.md b/docs/microservices-framework/functions/native-language-functions.md
@@ -327,7 +327,7 @@ The framework sees that your returned data has one of `code` or `success` meta-k
 **i.** If both are present, it looks for the other GSStatus keys and set them.  
 **ii.** If only code is present and lies between 200-399, then success is assumed to be true else false. It looks for the other GSStatus keys and set them.   
 **iii.** If only success is present, then code is assumed to be 200. It looks for the other GSStatus keys and set them.   
-**iv.** If it doesn't find any of these keys, it assumes all that you have returned is intended to be GSStatus.data then it adds `code: 200` and `success: true` internally to your response and create a `GSStatus` out of it to pass on to next tasks or workflows.   
+**iv.** If it doesn't find any of these keys, it assumes all that you have returned is intended to be GSStatus.data then it adds `code: 200` and `success: true` internally to your response and create a `GSStatus` out of it to pass on to next tasks.   
 
 <!-- **[Authz workflows](../authorization/authz-usecases.md/#authz-workflows)**
 
diff --git a/docs/microservices-framework/guide/advance-guide.md b/docs/microservices-framework/guide/advance-guide.md
@@ -54,7 +54,7 @@ Framework will give you below folder structure.
 ```
 
 :::tip Note
-- The framework generates different folders like [config](/docs/microservices-framework/config-and-mappings/config.md),[datasources](/docs/microservices-framework/datasources/overview.md) , [events](/docs/microservices-framework/event-sources/event-schema.md), [eventsources](/docs/microservices-framework/event-sources/overview.md), [functions](/docs/microservices-framework/workflows/overview.md), [mappings](/docs/microservices-framework/config-and-mappings/mappings.md), [plugins](/docs/microservices-framework/inline-scripting/script-plugins.md),etc
+- The framework generates different folders like [config](/docs/microservices-framework/config-and-mappings/config.md),[datasources](/docs/microservices-framework/datasources/overview.md) , [events](/docs/microservices-framework/event-sources/event-schema.md), [eventsources](/docs/microservices-framework/event-sources/overview.md), [functions](/docs/microservices-framework/functions/overview.md), [mappings](/docs/microservices-framework/config-and-mappings/mappings.md), [plugins](/docs/microservices-framework/inline-scripting/script-plugins.md),etc
 - The `eslintrc.json` file includes a curated list of recommended plugins that can be incorporated into the project.
 :::
 
diff --git a/docs/microservices-framework/guide/first-project.md b/docs/microservices-framework/guide/first-project.md
@@ -61,7 +61,7 @@ Godspeed generates a well-organized project structure:
       * [`datasources`](/docs/microservices-framework/datasources/overview.md)
       * [`events`](/docs/microservices-framework/event-sources/event-schema.md)
       * [`eventsources`](/docs/microservices-framework/event-sources/overview.md)
-      * [`functions`](/docs/microservices-framework/workflows/overview.md)
+      * [`functions`](/docs/microservices-framework/functions/overview.md)
       * [`mappings`](/docs/microservices-framework/config-and-mappings/mappings.md)
       * The `eslintrc.json` file contains a curated list of recommended ESLint plugins for your project.
       * Swagger specifications for your HTTP endpoints are configured in `src/eventsources/http.yaml`.
@@ -102,7 +102,7 @@ In this `helloworld.yaml` file:
   * **`schema: { type: string }`**: The `name` parameter must be a string, enforcing text input.
 
 :::tip
-In the Godspeed meta-framework, every API (REST or GraphQL) and message (websocket, cron, message bus) is referred to as an **`event`**. All events trigger workflows/functions, which act as event handlers (see the `fn:` instruction in the YAML above). Synchronous events return a response, while asynchronous events do not.
+In the Godspeed meta-framework, every API (REST or GraphQL) and message (websocket, cron, message bus) is referred to as an **`event`**. All events trigger functions, which act as event handlers (see the `fn:` instruction in the YAML above). Synchronous events return a response, while asynchronous events do not.
 
 This naming convention might be new to you. While the broader developer community typically refers to only `async events` (like Kafka or websocket messages) as `events`, Godspeed considers both synchronous APIs (REST, GraphQL) and asynchronous events (Message bus, websocket, cron) as `events`.
 :::
diff --git a/docs/microservices-framework/guide/walkthrough.md b/docs/microservices-framework/guide/walkthrough.md
@@ -11,10 +11,10 @@ In the previous section we got an understanding on how to setup a meta-framework
 Do ckeck the [tenets](../introduction/tenets.md), [design principles](../introduction/design-principles.md) and [guardrails](../introduction/guard-rails.md) baked into the meta-framework as part of its design - helping teams develop microservices based applications with best practices. 
 
 #### The three pillars
-Have you seen the [three pillars of abstraction](../introduction/design-principles.md#three-fundamental-abstractions) in the Meta-Framework?
+Have you seen the [three pillars of abstraction](../introduction/design-principles.md#fundamental-abstractions) in the Meta-Framework?
 
 - [Eventsources and event schemas](../event-sources/overview.md)
-- [Event handler functions (Pure functions)](../workflows/overview.md) 
+- [Event handler functions (Pure functions)](../functions/overview.md) 
 - [Datasources](../datasources/overview.md)
 
 You may want to check why you should use the [4th generation](https://godspeed.systems/blog/godspeed-fourth-generation-programming-framework) Meta-Framework versus creating apps using pure 3rd generation frameworks like Nodejs or Django stack from scratch.
@@ -27,7 +27,7 @@ You may want to check why you should use the [4th generation](https://godspeed.s
 :::tip
 As mentioned in the [getting started](./get-started.md) section all APIs and async events are together referred to as `events`. And hence any source like Express, Fastify, Kafka, Apollo Graphql are called [EventSources](../event-sources/overview.md).
 :::
-In [getting started](./get-started.md) section we created a project that includes a simple 'hello world' example which uses an http Express [eventsource](../event-sources/overview.md), [events](/docs/microservices-framework/event-sources/event-schema.md) and [event handler functions](/docs/microservices-framework/workflows/overview.md). 
+In [getting started](./get-started.md) section we created a project that includes a simple 'hello world' example which uses an http Express [eventsource](../event-sources/overview.md), [events](/docs/microservices-framework/event-sources/event-schema.md) and [event handler functions](/docs/microservices-framework/functions/overview.md). 
 
 
 Now we can move into further details.
@@ -89,7 +89,7 @@ For http service like Express, Fastify and Graphql, all events are defined in th
 
 ### Event Handler Functions
 
-[Event handlers](../workflows/overview.md) are **pure functions** which take input as JSON and return output as JSON, independent of the eventsource from which the event originated. This is again another adoption of decoupled architecture approach in the meta framework.
+[Event handlers](../functions/overview.md) are **pure functions** which take input as JSON and return output as JSON, independent of the eventsource from which the event originated. This is again another adoption of decoupled architecture approach in the meta framework.
 
 **Sample typescript event handler function**
 Here is how a function handler looks like.
@@ -112,7 +112,7 @@ export default function (ctx: GSContext) {
 }
 ```
 
-We are importing [GSContext](/docs/microservices-framework/workflows/native-language-functions#gscontext) & [GSStatus](/docs/microservices-framework/workflows/native-language-functions#gsstatus) from core package of meta-framework. Go to their respective section to more about them.
+We are importing [GSContext](/docs/microservices-framework/functions/native-language-functions#gscontext) & [GSStatus](/docs/microservices-framework/functions/native-language-functions#gsstatus) from core package of meta-framework. Go to their respective section to more about them.
 
 <!-- 
 **Sample YAML function**
diff --git a/docs/microservices-framework/how-to/call-datasource.md b/docs/microservices-framework/how-to/call-datasource.md
@@ -1,5 +1,5 @@
 
-# Invoking Datasource Clients from TypeScript Workflows
+# Invoking Datasource Clients from TypeScript functions
 
 In Godspeed, all configured datasources can be accessed through `ctx.datasources`. 
 
diff --git a/docs/microservices-framework/inline-scripting/overview.md b/docs/microservices-framework/inline-scripting/overview.md
@@ -1,6 +1,6 @@
 # Scripting
 
-Inline scripting involves embedding and executing code directly within Godspeed YAML code (e.g. workflows, datasources, eventsource, events, etc.,) enhancing seamless integration of script-based logic or functionality.   
+Inline scripting involves embedding and executing code directly within Godspeed YAML code (e.g. functions, datasources, eventsource, events, etc.,) enhancing seamless integration of script-based logic or functionality.   
 It is used directly by embedding the code/variables in `<% %>` tags. This code is evaluated whenever the yaml is needed to be evaluated e.g. at loadtime or runtime. 
      
 **Loadtime evaluation** There are some variables/code which should be evaluated at loadtime. For example, using [configs and mappings](../config-and-mappings/config.md) in datasources, events, or eventsources as given below:
@@ -40,11 +40,11 @@ port: <coffee% config.port %>
 ```
 <!-- 
 ## Scripting in workflows
-We use scripting in workflows/functions for dynamic evaluation of variables in `<% %>` tags.
+We use scripting in functions for dynamic evaluation of variables in `<% %>` tags.
 
 ### Accessing ctx properties using scripting
 
-The values of all [`ctx`](/docs/microservices-framework/workflows/native-language-functions.md#gscontext) properties can be assessed using scripting tags.
+The values of all [`ctx`](/docs/microservices-framework/functions/native-language-functions.md#gscontext) properties can be assessed using scripting tags.
 
 **1. Evaluating the inputs using scripting**
 
diff --git a/docs/microservices-framework/introduction/guard-rails.md b/docs/microservices-framework/introduction/guard-rails.md
@@ -7,7 +7,7 @@ At Godspeed, our development philosophy revolves around four core guardrails, sh
 
 ### 1.Schema driven development:
 
-Embracing the power of structured data, Godspeed follows a schema-driven development approach. This guardrail ensures that the events, workflows within the software are defined by clear and well-documented schemas. 
+Embracing the power of structured data, Godspeed follows a schema-driven development approach. This guardrail ensures that the events, functions within the software are defined by clear and well-documented schemas. 
 
 Dive deeper into the fascinating world of schema-driven development by watching the video below...
 
diff --git a/docs/microservices-framework/introduction/overview.md b/docs/microservices-framework/introduction/overview.md
diff --git a/docs/microservices-framework/vscode-extension/language-tools.md b/docs/microservices-framework/vscode-extension/language-tools.md
diff --git a/docs/tutorial-videos.json b/docs/tutorial-videos.json
diff --git a/docs/tutorial-videos.mdx b/docs/tutorial-videos.mdx
diff --git a/docs/welcome.md b/docs/welcome.md
diff --git a/sidebars.js b/sidebars.js
