I store last 5 messages in-memory (there's no way for anyone to access that. On restarts, it's gone). I know the consequences of this but it's not that noticeable because ChatGPT itself has some contextual memory. And I'm hosting on single node right now.
I made something similar too for my own use and opened it to public last week. Try it out maybe: https://t.me/spy16_avabot
Privacy Policy: I DO NOT log/store anything from users chat (except the numeric telegram-id and the language preference). And I DO NOT send any user info to OpenAI as well (I would rather shut it down)
It does not need access to database itself. Right now, you can simply explain the schema of your database and ask questions. It will simply generate queries.
But yes, the ideal setup would be to have a system that can connect to data sources and figure out the schema, etc. And for that, it needs to have on-prem. I am currently working on this.
I built https://github.com/spy16/connote with similar problems in mind when it comes to note-taking. It does not have all the features you are talking about though.
It's more of a command-line note-organizer tool that makes it slightly easier to index and manage bunch of markdown files.
If I understood correctly, your ask is basically that you don't want to see/hear anything about specific topics - Selective media blackout.
Like you already concluded, this to me, feels impossible (May be someone will come up with a brilliant way to do it ). Even if we just consider the text based consumption via news and other websites, it still feels super hard because we are not talking about filtering out some keywords.
You are totally right. It would be ideal to have a package called `users` which does everything related to user. But if proper care is not taken while laying out the packages and types that go inside, you might quickly run into cyclic-dependency issues (for the lack of better example: post requiring User type and User requiring post type). This does not happen in encoding/json or enconding/gob because of the fact that they are completely different domains and are simple enough. But in this project for example, they belong to the same domain and user and post entities have a relation between them.
I am not saying it's not possible to move towards the pattern you are suggesting. But since i decided to demonstrate Clean Architecture in this, i went with the current pattern which shows clear boundary between layers. In other words, what is used and what you are suggesting are just 2 patterns having their own advantages and disadvantages. It is probably not appropriate to call one or the other `non-Go way`.
But now that we have discussed this, i am interesting in trying that as well. Not sure if i should refactor or create a new project.
Thanks for the feedback. The layout used here is not something I came up with. It's an emerged pattern from popular open source projects. Like you said, most probably they all started with simple package and as the project grew abstracted out things finally leading to a similar layout. The layout itself is another community effort (https://github.com/golang-standards/project-layout).
This is not to say that the layout is a standard or the best possible one. It has it's advantages and disadvantages (a whole git repository and a blog article is dedicated to describe both aspects. Hence, I will not get into that discussion here). I chose the layout simply because it's already a well documented one. That being said, I will be more than happy to see other layout and even refactor the structure.
Open source projects generally are not typical web apps or REST API services. They are platforms or tools like docker, kubernetes, Hugo etc. While these projects are good usecases for studying golang code, they feel very complex due to their specific non-simple (if not complex) domain. My idea was to have a web app and API service project which has dead simple domain but highlights the coding practices so that newcomers can read and understand without having to understand what containers are etc.
Few other clarifications I would like to make:
- every directory is not essentially a package in Go. Only directories that have at least one go file are packages. Internal and PKG are not supposed to be packages in that sense. They are just a superficial boundaries between internal and public code.
- web directory is not a package in this project.. it contains static asset files.
- simplicity is something i absolutely love. That is the main reason I like golang. If you look past the outer structure of the project and dig into the code and packages, I think you will see the simplistic design inside. My other projects (e.g. https://github.com/spy16/radium) follow the simplistic method you explained.
Welcome to Golang!. I'm glad you found this useful. But i advise you to look at other patterns as well. This is just one of the patterns that can be used and may not be suitable for all usecases. For example, for smaller projects a much simpler layout with main or importable package at the root would work really well. Just to give an idea, my other project https://github.com/spy16/radium follows a very simple straightforward layout.
Thanks :). If you think it would fit into radium, send a PR. Would be more than happy to merge it. I was planning to create another git repository containing markdown files in some parsable format and integrate that with radium so that anyone can contribute easily.