potygen
draw.io
potygen | draw.io | |
---|---|---|
3 | 131 | |
86 | 38,715 | |
- | 1.2% | |
2.8 | 8.5 | |
6 months ago | 9 days ago | |
TypeScript | JavaScript | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
potygen
-
Monodraw
OMG this is one of my favorite tools paid for it all the way back when it went out. Have used it so many times just to write documentation for things like:
https://github.com/ivank/potygen/blob/main/packages/potygen/...
ASCII is just so versatile and allows you to put nice graphics in places where one does not expect, making things more easily understandable.
-
Pql, a pipelined query language that compiles to SQL (written in Go)
I also wrote a parser (in typescript) for postgres (https://github.com/ivank/potygen), and it turned out quite the educational experience - Learned _a lot_ about the intricacies of SQL, and how to build parsers in general.
Turned out in webdev there are a lot of instances where you actually want a parser - legacy places where they used to save things in plane text for example, and I started seeing the pattern everywhere.
Where I would have reached for some monstrosity of a regex to solve this, now I just whip out a recursive decent parser and call it a day, takes surprisingly small amount of code! (https://github.com/dmaevsky/rd-parse)
-
Is ORM still an anti-pattern?
I used to agree 100% with this sentiment, as dissatisfaction with available ORMs at the time (early days of doctrine in PHP) drove me to actually write my own. Turned out an amazing exercise in why orms are hard.
Anyway a few years later I was in a position to start things fresh with a new project so thought to myself, great lets try to do things right this time - so went all the way in the other direction - raw sql everywhere, with some great sql analyzer lib (https://github.com/ivank/potygen) that would strictly type and format with prettier all the queries - kinda plugged all the possible disadvantages of raw query usage and was a breeze to work with … for me.
What I learned was that ORMs have other purposes - they kinda force you to think about the data model (even if giving you fewer tools to do so) With the amount of docs and tutorials out there it allows even junior members of the team to feel confident about building the system. I’m pretty used to sql, and thinking in it and its abstractions is easy for me, but its a skill a lot of modern devs have not acquired with all of our document dbs and orms so it was really hard on them to switch from thinking in objects and the few ways orms allows you to link them, to thinking in tables and the vast amounts of operations and dependencies you can build with them. Indexable json fields, views, CTEs, window functions all that on top of the usual relation theory … it was quite a lot to learn.
And the thing is while you can solve a lot of problems with raw sql, orms usually have plugins and extensions that solve common problems, things like soft delete, i18n, logs and audit, etc. Its easy even if its far from simple. With raw sql you have to deal with all that yourself, and while it can be done and done cleanly, still require intuition about performance characteristics that a lot of new devs just don’t possess yet. You need to be an sql expert to solve those in a reasonable manner m, just an average dev could easily string along a few plugins and call it a day. Would it have great performance? Probably not. Would it hold some future pitfalls because they did not understand the underlying sql? Absolutely! But hay it will work, at least for a while. And to be fair they would easily do those mistakes with raw sql as well, but with far few resources to understand why it would fail, because orms fail in predictable ways and there is usually tons of relevant blog posts and such about how to fix it.
It just allows for an better learning curve - learn a bit, build, fail, learn more, fix, repeat. Whereas raw sql requires a big upfront “learn” cost, while still going through the “fail” step more often than not.
Now I’m trying out a fp query builder / ORM - elixir’s ecto with the hopes that it gives me the best of both worlds … time will tell.
draw.io
- Open-Source Lucidchart Alternative
-
Show HN: Open source database diagram editor
At first I thought this was drawio: https://www.drawio.com/ with which you can generate a schema diagram from SQL. Is this the other way around.
-
Monodraw
For anyone who is willing to use a webapp, I like drawio[0]. You can download locally[1] and self host (I just use the python webserver).
While finding the Github, I see they now actually package an Electron application, so that is probably worth exploring[2].
[0] https://www.drawio.com/
[1] https://github.com/jgraph/drawio
[2] https://github.com/jgraph/drawio-desktop
- Diagramming software for Linux, Windows, Browser – open-source
-
Are there any good FREE flowchart makers?
draw.io works nicely for flowcharts and other types of diagrams.
-
Is a fully open-source draw.io possible?
:
The source code authored by us in this repo is
-
Mastering Diagrams: A Professional Approach to Enhancing Visuals with ChatGPT and Mermaid
Another way that you can leverage the power of ChatGPT and mermaid is when you are using a software designing tool such as Draw.io and you want to skip the tedious task of creating a diagram from scratch and want to get a push at the begging and save your time for the creative part of the diagram.
-
Ask HN: Tell us about your project that's not done yet but you want feedback on
There are also mockups with more features, so ignore weird UI at first.
[1]: https://www.drawio.com
-
Draw.io
> Additional minified JavaScript files and Java libraries are used in this project. All of the licenses are deemed compatible with the Apache 2.0, nothing is GPL or AGPL, due dilgence is performed on all third-party code.
Here's an issue that was opened:
https://github.com/jgraph/drawio/issues/3782
> The file for converting the mermaid code to mxgaph xml is available only in minified version. the unminified version "mermaid2drawio.js" is missing. Please include that.
Answer:
> We do not supply the source to that file.
With such phrasing, for now, I'll consider drawio proprietary with some parts in Apache 2 (even if it's actually the majority of the code).
It might be possible to have a fork with some optional features related to these non provided files removed, if by luck no critical feature is impacted.
-
Do you use an external game visual flow tool for planning purposes? If so, what is it and why do you like it?
Specifically I've been working on an incremental game and I've been using https://www.drawio.com/ to help me plan out what I want the progression of features/unlocks to be as the player progresses through the game, what pre-requirements/events are for each feature/unlock, etc.
What are some alternatives?
cornucopia - Generate type-checked Rust from your PostgreSQL.
excalidraw - Virtual whiteboard for sketching hand-drawn like diagrams
jOOQ - jOOQ is the best way to write SQL in Java
mermaid - Generation of diagrams like flowcharts or sequence diagrams from text in a similar manner as markdown
NORM - NORM - No ORM framework
GoJS, a JavaScript Library for HTML Diagrams - JavaScript diagramming library for interactive flowcharts, org charts, design tools, planning tools, visual languages.
SQLpage - SQL-only webapp builder, empowering data analysts to build websites and applications quickly
plantuml - Generate diagrams from textual description
sqlite-fast - A high performance, low allocation SQLite wrapper targeting .NET Standard 2.0.
drawio-desktop - Official electron build of draw.io
sqlc - Generate type-safe code from SQL
HackMD - CodiMD - Realtime collaborative markdown notes on all platforms.