DEV Community: Gabriel

About Software Complexity...

Gabriel — Sat, 06 Jan 2024 18:40:21 +0000

Complexity is the worst enemy of a software developer. It makes organizations slow, businesses unscalable, and developers unhappy.

When starting a project from scratch, it feels clean, it's easy to reason about, and easy to extend with new features. That's a good feeling; I bet you've been in that situation and have thought:

"If only the big old boring project I need to maintain at work was like that..."

And wasn't it like that when it started? It's very likely that it was, then what happened? What made the project a big messy pile of code? Is my new clean and shiny project also destined to be like that if it grows?

Let's analyze the main sources of complexity in software:

Lack of skill/motivation:

Sometimes, developers just want to get paid. They want to solve the problem right in front of them as quickly as possible and collect a paycheck at the end of the month. That's fine, but that mentality naturally pushes developers to ship lazy and sub-optimal solutions as long as they solve the immediate problem. This adds up over time, stacking patches together making a code base exponentially harder to maintain as it grows.

RDD (Resume Driven Development):

Other developers just want to try out the new stuff. They are too passionate not to try out every new piece of technology that comes out, or maybe they just want a better resume in order to switch jobs. Simple problems are simple, but RDD is about making them complex by designing a system for 100x the expected scale, introducing every existing OOP pattern just for the sake of trying it out, or rewriting chunks of an app in the new framework just because it's new.

Evolving Business:

Here things get tricky. Businesses evolve, and the code in charge of providing features A, B, and C now needs to provide feature D, but it looks like feature D does not quite match with some assumptions made when shipping features A, B, and C. If there's time, a refactor for cleanly holding feature D can be done, but maybe there's not enough time, or maybe D is crazy different. This source of complexity tends to be unavoidable, but it can be greatly mitigated with good management, business vision, and reasonable deadlines.

The problem is just complex:

Maybe you are building the compiler for the next C++ replacement, or maybe you need to serve millions of requests per second with single-digit milliseconds latency. Some problems are just complex. This might be the only pleasurable source of complexity to have.

Visualizing a code base entropy

Imagine a complex code base that you've worked on. Try to imagine it as a whole, with all the files, all the folders, all the modules, all the packages...

What do you see?

I welcome you to Dep Tree, a tool that allows you to render the "entropy" of a code base, and visualize its complexity with a 3D force-directed graph.

3D force-directed graph

A 3D force-directed graph is a way of representing a graph in a three-dimensional space where nodes are placed based on some attraction/repulsion forces:

If a node is connected to another one by an edge, an attraction force will pull them together.
If two nodes are not connected, a repulsion force will try to take them apart.

In Dep Tree, nodes are source files, and if a file is importing another one, then an edge is created between them. If a file is importing another file, they will be rendered close together; otherwise, they will tend to be placed apart.

Additionally, if two files are in the same folder, an attraction force is created between them even if they are not importing each other, as it's assumed that they are somehow related.

How does a clean code base look like?

Clean code bases will be rendered with nodes grouped into clusters, and clusters of nodes clearly separated from each other. Something like this:

Otherwise, code bases that are messier, with no clear separation of modules, will tend to have all the nodes grouped together with no clear sense of clustering:

Visualize the entropy of well know open source projects

Here's the entropy visualization of some well-known projects:

(beware of these two, as they are very resource-intensive to render)

What's next?

If you like Dep Tree, feel free to stop by the GitHub repository and give it a star. Check out the README and you will find out that Dep Tree is far more than just a cool visualization tool; it can actually help you enforce your code base decoupling!

Hope you liked it, and see you soon!

Stream OpenAI's ChatGPT responses directly in the browser.

Gabriel — Tue, 20 Jun 2023 17:40:00 +0000

In this blog post you will learn how to stream OpenAI API responses directly in the browser, without the need for a backend as a middle-man between OpenAI and the browser application and without leaking your OpenAI API key to the world.

Stream the response through Signway

Signway is an open source and managed solution for generating pre-signed URLs, like the ones AWS S3 uses for sharing objects, but in this case for proxying correctly signed requests to destination APIs, and stream the response back. Its core is open source, so you can also host it yourself https://github.com/gabotechs/signway.

For following this tutorial you will need

Python +3.9 or greater installed in you system
An OpenAI Api key

Create a Signway Application

Go to Signway's web page and log into the console.
Once you log in you will be prompted to create an Application.
After giving a nice name to the Application, you will see a pop-up sowing the newly created Application ID and Secret. Copy them and store them in a safe place, we will need them later.
Once the Application is created, go to "Custom Headers" and add the "Authorization" header that will be sent to OpenAI.

Code a function that generates pre-signed URLs for Signway in Python 🐍

We will be using Python for this, but other languages could be used for generating pre-signed URLs.

First, create a virtual environment and install the Signway SDK:



python3 -m venv venv
source venv/bin/activate
pip install signway-sdk

Then create a script that generates pre-signed URLs. We will call this script sign.py:



# sign.py
from signway_sdk import sign_url
import os

print(sign_url(
  id=os.environ['SW_ID'],
  secret=os.environ['SW_SECRET'],
  host="https://api.signway.io",
  proxy_url="https://api.openai.com/v1/completions",
  expiry=900,
  method="POST"
))

Export the application secrets saved from the earlier step:



export SW_ID=""
export SW_SECRET=""

Remember to populate this variables with the Application ID and Application Secret that the Signway page gave you.

Executing this script gives us a URL that looks like this:



$ python3 sign.py

https://api.signway.io/?X-Sw-Algorithm=SW1-HMAC-SHA256&X-Sw-Credential=app-id%2F20230619&X-Sw-Date=20230619T195222Z&X-Sw-Expires=300&X-Sw-Proxy=https%3A%2F%2Fapi.openai.com%2Fv1%2Fcompletions&X-Sw-SignedHeaders=&X-Sw-Body=false&X-Sw-Signature=4aa60955f477eeb2bd556c41ecce3508d02b5b83bec9c0c188737998f73c5176

That is a signed URL, it can be safely transferred to clients as it does not contain any sensible information. In this case, we have set an expiration time of 15 mins, after that time the URL will be useless.

Create the frontend code that will stream the response

For this we will use a very simple example without using any framework:

Remeber to execute python3 sign.py and copy-paste the generated URL in the const URL = "" variable



<script>
    // Execute 'python3 sign.py' and paste the result URL
    const URL = ""

    fetch(URL, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
            model: "text-davinci-003",
            stream: true,
            prompt: "Say this is a test"
        }),
    }).then(async res => {
        const p = document.querySelector('#response')
        const reader = res.body.getReader()
        const decoder = new TextDecoder()
        while (true) {
            const { done, value } = await reader.read()
            p.innerText += decoder.decode(value)
            if (done) break
        }
    })
</script>
<html>
    <p id="response"/>
</html>

If you open this file in your browser you will see how the response from Open AI is streamed.

What's next?

You can do more things with Signway, like providing extra security by signing more things in the request, like the body or some headers. There is a cool tutorial about this here
The natural thing to do is to generate pre-signed URLs from a trusted source, like your backend, you can use the excellent FastAPI framework for that.
Make sure to pass by the Github repo and give it a star if you like it.
Feel free to play around the free tier of Signway Managed, but join the waitlist if you are willing to take it to the next level.

Using pre-signed URLs with OpenAI's API

Gabriel — Thu, 15 Jun 2023 17:25:47 +0000

While making an LLM product using OpenAI's API one of the first questions that arises is:

Why is OpenAI's API so slow?

Depending on the question and the prompt, the response can be quite long, and the longer it is, the longer it takes for ChatGPT's API to return the answer.

If you make a question in ChatGPT's official page, the response comes little by little, chunk by chunk, so even if it takes some time to return the full response, it is not that bad, as you are able to read the answer as it comes.

This is because ChatGPT's responses are streams of data, instead of just one big blob, so if you see that the response you make in your application is crazy slow, is because you are actually waiting for ChatGPT for generating the full response.

Then, how do I stream the response like in OpenAI's official web page?

Typically, you would make the request to OpenAI's API in your backend, as you need to pass your OpenAI API key, which is private to you, but re-streaming the data to the frontend can get really tricky depending on your stack and infra...

Then why not just make the query directly from the mobile/web app? you could just use fetch for querying OpenAI directly there. The answer is simple: because you do not want to leak your API KEY to the world.

But what if there was a way of querying OpenAI's API directly from the browser/mobile app without the need of leaking your API KEY...

Meet Signway, a service that brings the power of pre-signed URLs to your apps.

Signway is a high performant gateway that proxies pre-signed requests to the specified destination.

It uses the same cryptographic trick that AWS S3 uses with its pre-signed URLs, but it redirects requests to specified destinations instead of giving access to S3 objects.

You can see this more in detail in https://github.com/gabotechs/signway.

The idea is the following:

You configure Signway with an id and a secret. The managed version already does this for you, but you could also launch it with docker and configure it yourself.
In your backend, instead of querying OpenAI's API, you create a pre-signed url using Signway's Python SDK or JavaScript SDK. For that, you will need to use the same id and secret that Signway is configured with.
You send the generated pre-signed URL back to the frontend, and you make the request using fetch as if you where querying OpenAI's API but the URL is different (it is the Signway's pre-signed one)
The request will pass through Signway, who will validate that the request is authentic and has not expired. If everything looks great, you will see OpenAI's response directly in the client app, without any backend in the middle.

What's next?

Checkout this post if you want to learn how to use Signway for streaming ChatGPT responses in the browser.
There is an example here where you can hack around yourself with Signway using python for generating pre-signed URLs, curl for making http requests to OpenAI and docker for launching Signway in your local machine.
Check the github repo, as it has more detailed explanation of how this works.
If you want a fully managed solution, check Signway's website.

Dep Tree - A tool for validating your project's file dependency graph in the CI

Gabriel — Sun, 07 May 2023 12:14:13 +0000

What I built

Dep Tree is a CLI tool that is meant to be used either in CI systems or in the users local machines. It takes a JavaScript/TypeScript project as an input and validates/renders its file dependency graph.

Category Submission:

Maintainer Must-Haves

Dep Tree was designed to be used in CI systems in projects with a lot of people collaborating.

It is very common to setup some other static analysis tools like linters for automatically checking that contributors are following some established rules regarding code style.

Dep Tree does the same, but analything the file dependency graph in the project, failing the CI workflow if a contributor introduces a dependency in the code that couple things that should be decoupled.

App Link

https://github.com/gabotechs/dep-tree

Screenshots

Description

dep-tree is a cli tool that allows users to render their file dependency tree in the terminal, or check that it matches some dependency rules in CI systems.

It works with files, meaning that each file is a node in the dependency tree:

It starts from an entrypoint, which is usually the main executable file in a program or the file that exposes the contents of a library (like src/index.ts).
It reads its import statements, it makes a parent node out of the main file, and one child node for each imported file.

NOTE: it only takes into account local files, not files imported from external libraries.

That process is repeated recursively with all the child files, until the file dependency tree is formed.
If rendering the dependency tree in the terminal, the nodes will be placed in a human-readable way, and users can navigate through the graph using the keyboard.
If validating the dependency tree in a CI system, it will check that the dependencies between files match some boundaries declared in a .dep-tree.yml file.

Link to Source Code

https://github.com/gabotechs/dep-tree

Permissive License

MIT

Background (What made you decide to build this particular app? What inspired you?)

I work at propeldata.com, and our backend relies heavily on TypeScript.

As the company evolves, so does the code, and we had no way for ensuring that parts of a project that where initially designed to be decoupled, remain decoupled as more people contribute to the codebase.

We use dep-tree not only for better understanding the dependency flow in our applications, but also for validating in CI pipelines that new commits do not break any dependency rule.

How I built it (How did you utilize GitHub Actions or GitHub Codespaces? Did you learn something new along the way? Pick up a new skill?)

The project is written in Go, and it ships an executable binary with a CLI interface.

It's pipelines heavily rely on GitHub Actions for testing, linting and automatically releasing new versions of this binary. Each commit in a PR gets tested and linted, and on a merge to main, a new tag and a GitHub release is created (homebrew tap included).

dep-tree even ships its own GitHub Action https://github.com/gabotechs/dep-tree-action, that people can use out-of-the-box in their GitHub Actions pipelines.

The biggest lesson I got from setting up all this workflows was to be able to ship cross-compiled binaries for all the architectures and packaging them in a homebrew tap. GitHub Actions combined with https://goreleaser.com/ made this extremely easy.

Additional Resources/Info

I have another blog post here with some sample use cases that have proven to be relevant in our daily workflow: https://dev.to/gabotechs/dep-tree-a-tool-for-rendering-and-linting-your-projects-dependency-tree-in-the-terminal-25om

GraphQXL: the missing language extension

Gabriel — Sun, 12 Mar 2023 16:47:57 +0000

https://github.com/gabotechs/graphqxl

I work at Propel, a platform for creating serverless analytical data products, and we use GraphQL extensively to enable our customers to communicate with us.

Customers can connect their data with Propel using our API.
They can execute real-time analytic queries using GraphQL.
They can manage their account's resources using GraphQL API requests.

The problem

As you may imagine, Propel's GraphQL API is pretty big, and we want to keep it clean, maintainable, and as well-documented as possible. Unfortunately, sometimes GraphQL does not make things easy for us:

Common fields: While defining types, we need to copy-paste all the common fields across a lot of resources, fields like id, createdAt, modifiedBy...
CRUD inputs: When defining inputs that are meant to create or modify specific resources, there is a lot of repeated code for handling the input that creates the resource vs the one that modifies it.
Cursor pagination: We follow the GraphQL Cursor Connections Specification, and for each paginated resource, we need to define its own Edge and Connection even though all look the same.
Documentation: We document every field, and if there is a common field across different types or inputs, we need to maintain the documentation individually for each one.

All these problems can be boiled down to one: the lack of tools the GraphQL SDL specification provides for reusing code.

Code-first approach?

Using a code-first approach and auto-generating the GraphQL schema is a very common way to overcome this problem, but it has some disadvantages:

For customer-facing schemas, it can get tricky to control and review exactly what is being served to the customers, as there is no direct control of the GraphQL schema.
Ensuring that the documentation is consistent across all the resources is less ergonomic, as the documentation pieces are spread through the code base.
Non-technical people find it more difficult to contribute to new API features, as they will need to deal with actual code (TypeScript, Python, GoLang...).

But what if there is another way?

GraphQXL

GraphQXL is a language built on top of the GraphQL SDL syntax that solves the reusability problems of the original language.

It is framework-agnostic, as it is just an independent language that compiles down to plain GraphQL, that way it can be used with any programming language that supports it.

Here are some of GraphQXL’s features:

Field inheritance

One common pattern is to have an interface that defines some common fields that are shared across many types, for example, imagine that we want to reuse the field’s from this interface across multiple types:

interface Resource {
  id: ID!
  createdAt: Date!
  modifiedAt: Date
  createdBy: String!
  modifiedBy: String
}

In GraphQXL spread operators can be used to solve this:

Source GraphQXL

interface Resource {
  id: ID!
  createdAt: String!
  modifiedAt: String
  createdBy: String!
  modifiedBy: String
}

type User implements Resource {
  ...Resource
  username: String!
}

type Product implements Resource {
  ...Resource
  price: Float!
}

Compiled GraphQL

interface Resource {
  id: ID!
  createdAt: String!
  modifiedAt: String
  createdBy: String!
  modifiedBy: String
}

type User implements Resource {
  id: ID!
  createdAt: String!
  modifiedAt: String
  createdBy: String!
  modifiedBy: String
  username: String!
}

type Product implements Resource {
  id: ID!
  createdAt: String!
  modifiedAt: String
  createdBy: String!
  modifiedBy: String
  price: Float!
}

Try it in the GraphQXL explorer!

Generics

In GraphQL APIs there are usually some types or inputs that are very similar, and one clear example is the cursor-based pagination. Generics are really good at handling structures that look almost the same but have a small difference:

Source GraphQXL

type Product {
  price: Float!
}

type User {
  username: String!
}

"The ${{ variables.T }}'s Edge object for pagination"
type _Edge<T> {
  "The ${{ variables.T }}'s cursor that refers to the current node"
  cursor: String!
  "The ${{ variables.T }} itself"
  node: T!
}

"The Connection object for paginating across the ${{ variables.T }}s"
type _Connection<T> {
  "Metadata with the current page info"
  metadata: String!
  "List of ${{ variables.T }}s for the current page"
  edges: [T!]!
}

type ProductEdge = _Edge<Product>
type ProductConnection = _Connection<ProductEdge>
type UserEdge = _Edge<User>
type UserConnection = _Connection<UserEdge>

Compiled GraphQL

type Product {
  price: Float!
}

type User {
  username: String!
}

"The Product's Edge object for pagination"
type ProductEdge {
  "The Product's cursor that refers to the current node"
  cursor: String!
  "The Product itself"
  node: Product!
}

"The Connection object for paginating across the ProductEdges"
type ProductConnection {
  "Metadata with the current page info"
  metadata: String!
  "List of ProductEdges for the current page"
  edges: [ProductEdge!]!
}

"The User's Edge object for pagination"
type UserEdge {
  "The User's cursor that refers to the current node"
  cursor: String!
  "The User itself"
  node: User!
}

"The Connection object for paginating across the UserEdges"
type UserConnection {
  "Metadata with the current page info"
  metadata: String!
  "List of UserEdges for the current page"
  edges: [UserEdge!]!
}

Try it in the GraphQXL explorer!

💡 Note that the documentation for the Edges and the Connections is also autogenerated following the templating rules in the source GraphQXL file.

Import statements

There are different ways and tools developers can use to split a GraphQL schema into multiple files and merge them afterwards, but GraphQXL provides its own: import statements.

The behavior is pretty straightforward and predictable, given this file common-stuff.graphqxl:

type Identifier {
    id: ID!
}

It can be imported and reused into other .graphqxl files:

Source GraphQXL

import "common-stuff"

type Product {
    id: Identifier
    price: Float!
}

Compiled GraphQL

type Identifier {
    id: ID!
}

type Product {
    id: Identifier
    price: Float!
}

A good usage of this feature could end up in a final .graphqxl that looks like this:

import "products"
import "users"
import "subscriptions"
# import other entities

type Query {
  ..._ProductsQuery
  ..._UsersQuery
  ..._SubscriptionsQuer
  # queries for the other entities
}

type Mutation {
  ..._ProductsMutation
  ..._UsersMutation
  ..._SubscriptionsMutation
  # mutations for the other entities
}

schema {
  query: Query
  mutation: Mutation
}

Is there more?

There is a lot more! Feel free to

Check out Propel if you want to try what we have built in Propel,
Stop by the GraphQXL’s source repository https://github.com/gabotechs/graphqxl,
Play around in the GraphQXL explorer https://graphqxl-explorer.vercel.app,
or Read the GraphQXL book https://gabotechs.github.io/graphqxl.

Dep Tree - a tool for rendering and linting your project's dependency tree in the terminal

Gabriel — Tue, 21 Feb 2023 17:45:55 +0000

Dep Tree

https://github.com/gabotechs/dep-tree

Coding is a team sport, and team members should agree on conventions and strategies for taking projects across the line.

For example, team members may agree on a specific code style, and configure linters for enforcing it, that way no one can’t get their code merged without first be compliant with the styling rules.

Team members could also choose to agree on strategies for managing dependencies, something like “files in folder X” should never depend on “anything under folder Y”. A clean dependency management is crucial for a project’s maintainability and scalability in the long term, but there is not that many tools for enforcing dependency higiene as there is for code style higiene.

Dep Tree aims to solve this, not only by allowing developers to visualize in an interactive way their project’s dependency tree, but also by providing a tool for enforcing some user-defined dependency rules. Something like a linter, but for dependencies.

Dependency tree visualization

The first step for knowing how messy a project is, is by graphically visualizing it. Dep Tree allows rendering an interactive dependency tree in the terminal, which is super useful for understanding what pieces of a project depend on what, and what other things are correctly decoupled.

Take this project of mine as an example: https://github.com/gabotechs/react-gcode-viewer

That project is just a very simple React component library, and as usually, it has an entrypoint in src/index.ts. A very important thing to note, is that there is always an entrypoint, either the index file used for exposing a library, or the executable file with the program’s main function.

Running dep-tree render src/index.ts under that project’s root folder will render something like this in the terminal:

index.ts                                                                        
│                                                                               
└▷GCodeViewer/GCodeViewer.tsx                                                   
  │                                                                             
  ├▷GCodeViewer/GCodeModel.tsx                                                  
  └▷│GCodeViewer/gcode/reader/UrlReader.ts                                      
    ││                                                                          
    ├│▷GCodeViewer/GCodeLines.tsx                                               
    ├│▷│GCodeViewer/SceneElements/Camera.tsx                                    
    ├│▷│GCodeViewer/SceneElements/Floor.tsx                                     
    ├│▷│GCodeViewer/SceneElements/OrbitControls.tsx                             
    ├│▷│GCodeViewer/gcode/GCode.ts                                              
    │└▷││GCodeViewer/gcode/reader/base.ts                                       
    │  ││                                                                       
    │  │├─▷GCodeViewer/gcode/parser.ts                                          
    │  ││  │                                                                    
    └──┴┴──┴▷GCodeViewer/gcode/types.ts

💡 Dep Tree does not check third-party dependencies, it will only take into account the source code of the project, ignoring any dependency to a external library.

This is just copy-pasted from a terminal, but the truth is that users can navigate through the entries using the keyboard, and select specific entries for rendering their isolated dependency trees.

Dependency rules check

Once users are already aware of how messy their project’s dependencies are, they may choose to fix it and enforce some dependency rules. In the same way that developers configure linters for checking that new code matches the expected style, they can define rules to ensure that new code does not introduce dependencies between parts of the application that are meant to be decoupled.

In Dep Tree, this rules are defined in a .dep-tree.yml file in the root of the project with the following structure:

entrypoints:
  - src/index.ts
allow:
  "this-folder-can-only-depend-on.../**":
    - "this/*.ts"
    - "and-this/*.ts"
deny:
  "this-one-cannot-depend-on.../**":
    - "not-this/*.ts"
    - "neither-this/*.ts"

Some real life examples:

⚛ React `pages` and `components`

Imagine a React application, with a pages folder and a components folder. Probably, files under pages will use the reusable components defined in components for building whole pages, but components are just isolated testable components that should not depend on page-specific details:

entrypoints:
  - src/app.tsx
deny:
  "src/components/**/*.tsx":
    - "src/pages/**"

running dep-tree check with this .dep-tree.yml file would fail if any component tries to depend on something that lives under the pages folder.

🔧 The classic `utils` folder

Who hasn’t dealt with this? a project that starts being a small thing, with some innocent helper functions that are placed under a utils folder. Then the project keeps growing, every new addition has its own “util” function or class, and because of the vague and generic meaning of the word “util”, everything can be considered a “util”. Some months later half of the project ends up living in a utils folder.

entrypoints:
  - src/main.ts
allow:
  "src/utils/**":
    - "src/utils/**"

This config will limit files under src/utils to only import other files under src/utils. That way a “util” can’t depend on parts of the application with business logic important for a specific functionality, developers are forced to colocate things that are designed for functionality X under the folder designed for functionality X, and the utils folder is left just for some generic and basic helper functions.

🔄 Dependency inversion

Last letter of the SOLID principles and one of the most powerful tools in software development, but lets directly dive-in in a real world example:

An application that is in charge of managing users, that uses MySQL as a database, will probably have some MySQL client code under src/mysql-client, and some user management code under src/users. As the application is using MySQL for persisting user information, then the code under src/users will depend on src/mysql-client for storing the users.

The src/users high level module is depending on the src/mysql-client low level module, which has some serious impact in testability in isolation of infrastructure-specific details, or in other words, not needing a whole MySQL database running just for testing src/users.

Dependency inversion can help here by breaking the dependency between both modules, putting an interface in between, and making src/mysql-client depend on that interface. But explaining how dependency inversion work is out of the scope here, so let's see directly how Dep Tree can help here:

entrypoints:
  - src/main.ts
deny:
  "src/users/**":
    - "src/mysql-client/**"

This will enforce the src/users module to not depend on MySQL-specific details.

Even better, if all the infrastructure-specific code is gathered under a infra package, the dependency banning can go even further:

entrypoints:
  - src/main.ts
deny:
  "src/users/**":
    - "infra/**"

Summary

Dep Tree aims to be another automated tool for helping in the maintainability of medium/large code bases. It helps to understand the dependency flow of an application and provides tools for validating it against the rules defined in a configuration file.

If you find it helpful, feel free to stop by the source repository https://github.com/gabotechs/dep-tree and give it a try, feedback is much appreciated!

DEV Community: Gabriel

About Software Complexity...

Lack of skill/motivation:

RDD (Resume Driven Development):

Evolving Business:

The problem is just complex:

Visualizing a code base entropy

3D force-directed graph

How does a clean code base look like?

Visualize the entropy of well know open source projects

What's next?

Stream OpenAI's ChatGPT responses directly in the browser.

Stream the response through Signway

For following this tutorial you will need

Create a Signway Application

Code a function that generates pre-signed URLs for Signway in Python 🐍

Create the frontend code that will stream the response

What's next?

Using pre-signed URLs with OpenAI's API

Why is OpenAI's API so slow?

Then, how do I stream the response like in OpenAI's official web page?

Meet Signway, a service that brings the power of pre-signed URLs to your apps.

What's next?

Dep Tree - A tool for validating your project's file dependency graph in the CI

What I built

Category Submission:

App Link

Screenshots

Description

Link to Source Code

Permissive License

Background (What made you decide to build this particular app? What inspired you?)

How I built it (How did you utilize GitHub Actions or GitHub Codespaces? Did you learn something new along the way? Pick up a new skill?)

Additional Resources/Info

GraphQXL: the missing language extension

The problem

Code-first approach?

GraphQXL

Field inheritance

Generics

Import statements

Is there more?

Dep Tree - a tool for rendering and linting your project's dependency tree in the terminal

Dep Tree

Dependency tree visualization

Dependency rules check

⚛ React pages and components

🔧 The classic utils folder

🔄 Dependency inversion

Summary

⚛ React `pages` and `components`

🔧 The classic `utils` folder