Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Manifest: A 1-file micro-back end

github.com

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Manifest: A 1-file micro-back end

#32

Post by TheRealPomax »

yakshaving_jgt wrote: post #21

If I need a 1-file backend, I can pretty easily do this in Haskell. I have more trust in this still working next year also. {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE QuasiQuotes #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} import Yesod data App = App mkYesod "App" [parseRoutes| / HomeR GET |] instance Yesod App getHomeR :: Handler Html getHomeR = defaultLayout [whamlet|Look at me. Just one…

Ah yes. But let's make sure form posts actually work eh? How hard could it be to add CSRF to our pa- oh no https://github.com/yesodweb/yesod-cookbook/blob/master/cookb...

Re: Manifest: A 1-file micro-back end

#33

Post by oulipo »

Could go all the way, and instead of a YAML, just do a literate Markdown, so you can embed the code and documentation, something like

    # My Pokemon backend
    
    ## Entities
    
    Let's start by defining my entities, I want to model Pokemons, so I'll just add this:
    ```yaml
    Entities:
    - Pokemons:
      - Bulbasaur...
    ```

Re: Manifest: A 1-file micro-back end

#34

Post by yakshaving_jgt »

TheRealPomax wrote: post #32
yakshaving_jgt wrote: post #21

If I need a 1-file backend, I can pretty easily do this in Haskell. I have more trust in this still working next year also. {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE QuasiQuotes #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} import Yesod data App = App mkYesod "App" [parseRoutes| / HomeR GET |] instance Yesod App getHomeR :: Handler Html getHomeR = defaultLayout [whamlet|Look at me. Just one…

Ah yes. But let's make sure form posts actually work eh? How hard could it be to add CSRF to our pa- oh no https://github.com/yesodweb/yesod-cookbook/blob/master/cookb...

Right. Add the middleware and use the yesod-form library. Pretty easy.

Re: Manifest: A 1-file micro-back end

#37

Post by ur-whale »

Whenever I look at a new project on github, the first thing I do is try to get to the "core" of the source code, where the actual code that implements the basic feature actually lives.

One quality metric that I've noticed my brain has developed over the years is how deep in the directory hierarchy I have to dive to finally find some actual code amidst the mess of config files, readmes, yaml things, json metadata and various other crap that carry essentially no semantic.

It's been surprising how accurately this metric measures the overall quality of the project.

Large Java codebases are one of the worst offenders in that regard.

Unfortunately by this metric, and independent of anything else, this project does not fare well at all ... I give you my first attempt at actually finding the code, depth=

https://github.com/mnfst/manifest/blob/master/packages/core/...

depth=6 below project top dir (ignoring github-added crap)

Re: Manifest: A 1-file micro-back end

#38

Post by stosssik »

SwiftyBug wrote: post #7
oliwary wrote: post #5

Earlier quoted context omitted.

Are you aware of pocketbase? https://pocketbase.io/ I think it could work for your usecase, even though its generally focused on being a backend. I have had a very nice experience.

I love Pocketbase! In particular using it as framework. I use it as CMS and auth system and add my custom application routes to the server. It's very easy to seamlessly leverage all its infrastructure.

Hi, Manifest founder here.

PocketBase is great too. Manifest brings something different: it's fully code-based, so you can stay in your IDE, use AI tools like Copilot or Cursor to build your backend, and keep everything versioned in Git. It fits naturally into dev workflows, and we’ve got more coming soon on the AI side, both around AI and new features.

Re: Manifest: A 1-file micro-back end

#40

Post by crooked-v »

lexicality wrote: post #20

The lack of object level permissions is a really spectacular footgun and the fact that it's not even on the roadmap is concerning. Want to allow users to set their own name? I hope you're OK with any user being able to update any field of any other user too! Added a new entry and didn't specify a policy for every single available action? They default to unauthenticated access! > If no policy is specified for a rule,…

That default by itself makes me want to run away from this project, fast, because it implies there are similar business-destroying footguns elsewhere.
Post reply on HN