A couple of years ago, I wouldn't have believed we would be seeing essentially zeroconf TLS/PKI in software anytime soon. Letsencrypt, the "encrypt everything" movement, and people like Steve, Ponzu's author, have improved internet security tremendously at a time when it is critically needed.
Sort of. If you're OK with manually updating the certificates after initially fetching them from L.E., then you can use them. However L.E. must be able to communicate directly with the server via HTTP to prove authority and send you the certificate.
There are other tests that the ACME protocol can do to determine authority over a domain name, but Ponzu's implementation doesn't handle them.
Hi all - Ponzu's author here. I was pleasantly surprised to see this post today. I'm reading through comments and will be releasing some video content as an overview of the CMS and server shortly - hoping to address any questions I see here.
If you get a chance to try it out and have questions or issues, I'm in the #ponzu channel in the Gopher's slack org: https://invite.slack.golangbridge.org/ feel free to ping me there or open an issue on Github.
Nice to see Ponzu getting some attention. I used Ponzu to create the GopherCon 2017 site this year (gophercon.com) and really enjoyed how easy it was to put content up quickly. I created Go helpers -- only useful if your website is in Go: github.com/bketelsen/ponzi && github.com/bketelsen/ponzigen
Overall A+ to Ponzu. I'm on my 6th ponzu site now, still love it.
Looks spiffy. I like the approach of keeping even the database as part of the application. I think it makes projects a lot more like appliances, which can really be more plug-and-play. I see a lot of databases moving towards the application layer (CouchDB, Firebase), but it's interesting to see applications going the other way.
Lastly, here's to the hope of an exploit named "Pwnzu" never getting released! It's simply too good of a name.
Does look pretty slick, but I imagine the flat nature of the content items will be limiting. In the example, song has an artist. But artist is a string vs a related content item.
I can't tell if that's an MVP type decision and will change later, or a design decision that won't change in the future.
Hi - you can make a relationship using the built in addon package, github.com/bosssauce/reference
The reference is stored as a string (or []string if you opt for a reference.SelectRepeater input func), but the value stored as a reference is actually a URL path to the content as it would be accessed via the Content API. This becomes very powerful when you enable HTTP/2 Server Push, and declare the referenced content to be pushed when it's parent content is requested.
The underlying data looks like this:
Song
id: 1
title: "Take Me Home, Country Roads"
artist: "/api/content?type=Artist&id=2"
If you enable H2 Server Push by implementing the Pushable interface (add a Push method that returns a []string of the JSON field names to push), the server will know to make a response for the referenced Artist field and push it down to the client when the parent Song is requested.
Definitely will -- thank you for taking the time to read through.. it's hard for me to know where the docs are too light sometimes. (besides generally everywhere)
Kudos to the creators for getting the CMS field definitions right by allowing arbitrary amounts and types of fields!
It's so annoying to me that so many CMS's and static site generators start out with the assumption of 1 big rich text / markdown "body" for content and treat everything else on the page as miscellaneous stuff (meta-fields, yaml front-matter, etc).
Imagine the case of a generic news article: the body of the post can contain text, photos, pull quotes, videos, a slideshow, audio content, etc. The CMS needs to enable users to add all of that content and expose via the API to multiple clients (web, mobile, feeds, etc).
I always thought that fields are generally poor for that - html is pretty good and has ways to structure all those things, and they can be extracted and styled for different clients.
You can still do that with most field oriented CMS packages. The field interface is generally admin facing only.
The user facing html templates have variables that map back to those fields. So, all the expression of HTML, but with the actual data in fields.
Handy for things like addresses. You can render a map or just text, or both. The fact that it's structured data would allow for proximity searching. Where each "post" is say, a restaurant location.
Similar for things like tags, so that you have built in taxonomy. Separate spaces for tags too, so that you could have a topic taxonomy as well as a completely separate taxonomy that doesn't pollute that space. Like an author taxonomy or similar.
HTML as a data entry format is error prone, and HTML as a cross-platform data source requires a lot of tooling and unreliability compared with a properly-structured field-driven JSON API
havent looked at the reqdme or rtfa, but ponsu, if i'm not mistaken, is a sauce in japan used for dipping, it consists of soy sauce and citrus/lemon/lime flavoring, great with raw, grated daikon radish.
in terms of this project, excellent, i actually wrote a lot of web apps using golang and found the main deficiency to be the templates, tried amber, ace, and even the default mustache/handlebars, but still think jade and haml beat those hands down. i did see a few ports of jade, but wqsnt certain about the stability or completeness of it.
I spoke to a Japanese programmer friend on his opinion on projects named after Japanese words. His personal take was that many were at cringe level. Not just him, his group of friends regularly chat about the "cringiness" in their line group.
I promptly shared my project based on a Japanese name and provided entertainment for a few mins.
I was apprehensive about BoltDB too, at first, but after giving it a shot I've really taken to it and come to appreciate the reliability and flexibility it offers. It's not well-suited for all cases, just those where dropping in high-performance transactional persistence into an app meets your needs.
As it keeps gaining traction and popularity, more and better tooling will inevitably be created to scratch itches :)
Auth for API usage is up to the user to implement, but you could borrow code from the internal system/admin/user package to do password based auth & check JWTs. All of the API interactions w/ the system have hooks (see here: https://github.com/ponzu-cms/ponzu/blob/master/system/item/i...) so you can do auth verification, data validation, etc all within the req/res lifecycle.
According to the README it depends on golang.org/x/crypto/bcrypt and github.com/nilslice/jwt so it seems likely to have authentication on board and a way of using JWT tokens for API access.
Well, I am not affiliated with bleve, but actively use it in my project where the data are in BoltDb but index is stored separately in bleve. It's really awesome package.
I agree :) sorry I wasn't more clear, but I have indexing already added with Bleve - it's in the ponzu-dev branch of the repo now. If you get a chance to browse the code lmk if you spot anything I have done incorrectly!
A couple of years ago, I wouldn't have believed we would be seeing essentially zeroconf TLS/PKI in software anytime soon. Letsencrypt, the "encrypt everything" movement, and people like Steve, Ponzu's author, have improved internet security tremendously at a time when it is critically needed.