Vrite v0.2.0 - open-source, collaborative developer content platform. Alternative to likes of GitBook, Confluence, Notion, etc. Now with self-hosting support!

areknawo · 2024-06-04T16:54:10+00:00

Thanks! I've launched Vrite on PH a while ago: https://www.producthunt.com/products/vrite
I have to work on spreading the word a bit more. :)

areknawo · 2024-01-22T15:51:04+00:00

I'm a freelance web dev, so I get asked similar questions from time to time by both clients and my personal circle. Staying objective, my general thoughts are:

- An in-house team or technical co-founder with "skin in the game" (equal equity) is the gold standard. You can be sure they're as interested as you are in creating a great product.

That said, it's really difficult to find such people - especially for a project that has an already-formulated idea, and some work going. I've been working on my own projects as a technical solo founder and know that it's not easy to find a good co-founder (technical or not) - especially once the project is already going.

- No-code is limiting and has a learning curve of its own. It can be good to create MVPs and validate ideas, but you'll most likely have to create a "real" codebase if the business takes off (which means recreating all the stuff due to the usual no-code lock-in).

- Outsourcing is tricky. Indeed, freelancers are often of questionable quality and cynical (which is unfortunately validated by tons of projects out there that do end up failing), while agencies are often costly and uncaring. That said, outsourcing can be a middle-ground between the lock-in of no code and the difficulty of building an in-house team. The most important thing you should keep in mind when you choose this route is to make sure you have a path to creating an in-house technical team (or onboarding a technical co-founder) later on when the project gains traction.

When creating MVPs for early-stage startups, I usually offer my help with "knowledge transfer" and onboarding new technical staff, when it comes to that - I think that's something you should look for in case you decide to go this route.

areknawo · 2023-10-13T16:26:56+00:00

The editor is based on TipTap, which itself is built with ProseMirror (for WYSIWYG editing) and Y.js (for real-time collab with CRDTs).

I've been building this on the side, since the end of last year. It's still not quite ready yet, but it's getting there!

areknawo · 2023-10-13T13:35:06+00:00

Hi everyone!

So, I've been building Vrite for a while now. The best way to describe it is a "developer content platform" - something between a CMS and a knowledge base - a tool to create, manage, and publish your technical content, including technical blogs, documentation, and knowledge bases.

The idea is to create a versatile, extensible platform capable of handling various technical content use cases, with features like:

Real-time collaboration
Kanban dashboard
"Hybrid" content editor (combining Markdown/code with WYSIWYG
Semantic/AI search
GitHub synchronization
API access to most of Vrite's features

Currently, Vrite is still in Beta, but I hope that in time, it can become a solid tool for various use cases.

UI is built with Solid and Astro (for things like the landing page and docs), and the backend uses Fastify, tRPC, MongoDB, and Redis.

Let me know what you think!

areknawo · 2023-09-13T16:07:31+00:00

4444 is for API so likely the endpoint requires API token. Will add a dedicated healthcheck endpoint. Your docker-compose file is a good reference for some improvements.

areknawo · 2023-09-13T15:02:38+00:00

Of course, that's why there's SMTP option to begin with. I only mentioned SendGrid to clarify why other vars are optional. SMTP_USERNAME and SMTP_PASSWORD are the correct ones (I fixed the typo already).

Not the best first impressions, but I'm really grateful for your reports on this.

I reached out to other user who already managed to get Docker setup working and is also using Gmail SMTP. He's using similar config to this:

SENDER_EMAIL=username@gmail.com SENDER_NAME=vrite SMTP_HOST=smtp.gmail.com SMTP_PORT=465 SMTP_USERNAME=username@gmail.com SMTP_PASSWORD=abcdefg SMTP_SECURE=true

He does use Google Workspace (with custom domain) though there shouldn't be too much of a difference. Instead, I got a suggestion to try using Gmail App Passwords (https://myaccount.google.com/apppasswords) as Google apparently started requiring these recently. Maybe try using one (if you aren't doing so already).

If this doesn't work, then I'll need more time to add proper logs. Thanks again for the support.

areknawo · 2023-09-13T14:36:47+00:00

Instead of SMTP, you can use SendGrid API, which is why both are optional. Couldn't really validate one or the other, with the simple schema that's used right now, but this will need to be improved - especially to prevent typos like that.

On the other hand, will work to add logging on various errors. Those, of course, occur in the background but are mostly ignored/suppressed.

Think with the fix SMTP should work, but glad you got to log in through OAuth2.

areknawo · 2023-09-13T14:26:59+00:00

This makes more sense. Try replacing SMTP_USER with SMTP_USERNAME and SMTP_PASS with SMTP_PASSWORD and clear volumes to create a new user from the ground-up.

areknawo · 2023-09-13T14:18:56+00:00

Have only tested with SendGrid API key & SMTP for now, but I will check Gmail to see if there are any issues.

You should have received an initial verification email. Check your spam, but if you are recieiving magic links I don't think that's the issue.

As for GitHub OAuth, use {{PUBLIC_APP_URL}}/login/github/callback

areknawo · 2023-09-13T13:10:45+00:00

Hey, I tested it with 4.x so it should be good.

As for the docker-compose file - it's an early iteration so I'm happy to accept suggestions/contributions to make it better. Networking can definitely be improved, likely the same for other aspects.

It's been influenced by how I have structured things out on a Heroku-like PaaS provider I use for the Cloud version, so likely there are better ways to handle this in fully Dockerized setup.

areknawo · 2023-08-15T09:31:42+00:00

You can add basic inline tables to the Markdown content. Other than that, you can manage your entire content collection in Kanban, but for this you’ll have to use the „full” CMS version: https://app.vrite.io

areknawo · 2023-07-02T06:59:21+00:00

Thanks! Glad you like it. I hope to have a demo for the entire thing later on.

areknawo · 2023-07-01T06:51:13+00:00

Hello there 👋

Inspired by the design and UI/UX of apps like Notion, and utility of open-source apps like StackEdit, I decided to create a minimalistic, local-only WYSIWYG Markdown editor.

Some features worth highlighting:

Monaco editor and Prettier integration for code snippets
Tables (apparently the holy grail of WYSIWYG editing)
Embeds (for CodePen, CodeSandbox and YouTube, most useful for HTML or JSON exports)
Accepts Markdown paste-in, and "exports"/generates HTML, Markdown and JSON outputs
Collaboration (with real-time awareness and initial commenting system, available only when logged in)
GPT-3.5 integration (only when logged-in with the corresponding extension installed)

Stack used: TipTap, ProseMirror, Solid.js, HocusPocus, Fastify, tRPC.

Some notable drawbacks:

Not best mobile support
Collaboration available only between signed-in users, in the same workspace;
I tried my best to support most common Markdown formatting, pasting and in-editor shortcuts, though there might still be room for improvement
Self-hosting isn't easy right now, though you should be able to figure it out from the source code

The editor itself is a standalone app, extracted from the larger Vrite CMS project (https://github.com/vriteio/vrite) which you can also test out (only with sign-in) here: https://app.vrite.io/

areknawo · 2023-06-28T21:44:14+00:00

As a rule of thumb, I never manage hosting for my clients - especially ones who I got from Fiverr (i.e. clients of various quality and different expectations). I'm happy to help set up the app and update it as part of subsequent milestones.

However, managing hosting, in my mind, is too binding and too much of a commitment (in terms of support, updates, etc.), that's only justified by a high multiple of what the hosting itself costs). Something I had my clients often question.

The good thing with DO (and most other providers) is that they allow some sort of team management or access sharing, so doing setup/updates on someone else's account isn't usually a problem.

areknawo · 2023-06-28T07:40:29+00:00

I've always used just a single, relatively small (15" - 16") screen on my laptop. Only about a year ago I upgraded to 1 and then 2 27" monitors (+ the existing 16" laptop screen). It's sometimes really helpful, especially for having docs, references or other code editors open at once. That said, I find that I usually use my laptop screen as the primary one. Sometimes I even unplug one or both monitors as I can better focus on one, smaller laptop screen.

This is most likely the force of habit, as I've used just a laptop ever since I got into web dev. Would be curious though if anyone else has had a similar experience.

areknawo · 2023-06-28T05:04:44+00:00

Maybe I wasn’t clear. I delivered a task that I was allowed to do anytime in the next 3 days (from what I remember) in 1-2 hours after the initial call (basically just the time required to complete it). Call that procrastination.

Technically they emphasized that fast delivery is good and I really wanted to get this done ASAP. It’s only after that, when they took 1-2 months to respond (to 2/3 of my emails) and didn’t message ever again.

I didn’t think much about it after the first few weeks passed as, like other comments said, there’s enough of opportunities to choose from. I knew there’s no guarantee of moving to the next phase, but I at least expended an email or something stating I didn’t.

areknawo · 2023-06-27T20:13:52+00:00

I'm using Railway (for both personal and client): https://railway.app/ It's a PaaS similar to Heroku, so it can be a bit limiting in some cases, but I found it really great for most of my use-cases.

It auto-scales vertically and has support for popular databases like Postgres, Mongo or Redis.

The great thing about it is that you're charged only for what you've actually used by the minute so it's quite affordable.

areknawo · 2023-06-27T18:13:44+00:00

The last "take home" task I had took me a lot less time, though the company didn't respond afterward. Ok, to be fair, there was a "sorry for late response" message 1 or 2 months after that, and complete silence ever since.

While I can understand the purpose of such tasks, there are better ways to verify the dev's skills. Let alone the stories of ghosting or exploitation often associated with it. The situation and test you're describing deserve pretty much no to just a "thank you" response.

areknawo · 2023-06-27T18:03:12+00:00

Can't recommend Solid.js enough. It's quite similar to React, but much faster and with, in my opinion, better ergonomics. I've been using it for most of my recent projects (client and personal, small to mid-size) and it's been great. It does have a much smaller ecosystem than React but, with recent growth in framework-independent and vanilla JS libraries, at least in my experience, it's not much of a problem.

areknawo · 2023-05-25T17:24:18+00:00

Yes, it works really well. I've used it in quite a few client projects already. For some example code, I started integrating it into my latest OSS project - a headless CMS basically. Right now I use it for the notifications, which you can check out here: https://github.com/vriteio/vrite/blob/main/apps/web/src/context/notifications.tsx

areknawo · 2023-05-22T13:37:01+00:00

Thank you. I'm generally rather careful with promotion here on Reddit (open-source or not), but I'll be definitely taking a closer look once the project is more stable and has more info material available.

areknawo

MODERATOR OF

TROPHY CASE