no0dles's comments

On: Show HN: Hammerkit – Build Tool

[no0dles]

Awesome, will do! Did use JSON schema before, but didn't know it can be used for yaml as well.

On: Show HN: Hammerkit – Build Tool

[no0dles]

Thats very true, I used taskfile personally and professionally for a few projects and encoutered some problems I tried to solve with this project. I even tried to contribute there, but it was not that easy, since I am not that fluent in go

[stephanos2k → no0dles]

I'm curious: what kind of problems?

[no0dles → stephanos2k]

maybe problems is the wrong term, lets call it features I was missing.

  - without docker images in tasks tooling was not always the same on different machines
  - a docker image that can be used for gitlab ci
  - caching on CI systems was a huge effort, requiring to specify all .task directories and build directories
  - limited includes of other build files, no nesting or loops, making project style taskfiles not possible
  - the cwd of includes is not relative to the reference taskfile

and there are some, which are not solved yet in hammerkit, but planned:

  - detect changes in cwd during commands, for example with `cd ..`
  - a service definition, allowing to use databases with some healthchecks to detect startup delays
  - limiting cpu/memory of build steps / limiting tasks that are executed parallel by resource available

On: Show HN: Hammerkit – Build Tool

[no0dles]

Thank you very much for your feedback :). I did take a look at both (make and bazel) before I decided to start this project.

What I was missing in make was the containerization which enables running tasks inside container and take leverage of the installed tools there. That keeps the requirements on available tooling low and makes it als easier for cross platform development.

Bazel on the other side was very hard to get into and felt really complex. I am sure it's a great build tool and you can archive great things, but I thought maybe I could create something simpler that's almost as relable without the complexity. I am sure I miss a lot of features in my project that bazel covers and hope I do not end up with the same complexity.

At least I will learn a lot, either way :)

On: Don’t we all just want to use SQL on the front end...

[no0dles]

I had the same question a year ago and create a side project on that topic. The solution was is very close to the firebase approach, writing security rules. Those rules whitelist sql statements and give some some flexibility by defining query parameters and having a context object that contains userIds and so on. For example:

frontend sql statement as a json object:

  {
    select: { 
      name: field(Project, 'name') 
    },
    from: table(Project),
    where: equal(field(Project, 'ownerUsername'), '<my-user-id>'),
  }

and here a rule configured on the backend:

  const rules = [
    allow(authorized(), {
      select: {
        name: field(Project, 'name'),
      },
      from: table(Project),
      where: equal(field(Project, 'ownerUsername'), requestContext().userId),
    })
  ],

Sadly documentation is quite poor for now, but you can check it out here https://github.com/no0dles/daita

Edit: code formatting