Hacker News new | comments | ask | show | jobs | submit login
Ponzu – An open-source HTTP server framework and CMS in Go (github.com)
204 points by wilsonfiifi on Apr 9, 2017 | hide | past | web | favorite | 41 comments

> Automatic & Free SSL/TLS

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.

Thank you, but all credit is due to the Let's Encrypt team. It is an amazing thing they have done.


Quick question, must the server use "Let's Encrypt" be public on internet to use it?

Like: Can I use private ip (10.1.1.x) behind the NAT and still use "Let's Encrypt" + your CMS/server?


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.

Sorry if that doesn't fully answer your question.

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:


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.

Ahh, okay. That seems straightforward. Might be good to reference that in the main documentation.

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)

Is it flat like wikipedia or flat like S3?

Not sure. I don't see any support for item relationships. It could just be a lack of documentation though.

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).

Sorry, I've never used a CMS or managed a blog... but I'm curious about the use case and benefits of having arbitrary fields.

Is it for meta information about a post? Are those fields injected into a post somehow? How are those fields used? (I'm ignorant of CMSs)

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.

It generally limits you though, eg one video per article etc.

Depends on the CMS. Many have repeating fields that you reference in an array style notation from templates, or via loops.

Others allow content relationships, where videos are their own object, set not to be published alone, but embeddable into, say posts.

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

If you have the luxury of convincing your users to learn markdown instead of structured fields you'll have a far simpler and extendable solution.

Obviously rarely the case, but worth having the conversation.

Any decent CMS would add tooling there (yes, they don't they just treat the HTML is WYSIWYG, but that is where the tooling should be)

Looks interesting, it would be nice if the ”Why?“ section contained comparisons to other CMSs.

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.

Go visit Japan and check out English usage on their T shirts

Boltdb sounds neat, but I swear no off-the-shelf tooling supports it.

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 :)

Couldn't see any authentication system in Readme, Is there any auth mechanism that can be used for API usage?

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.

How hard do you think it would be to add SAML/OAUTH2 authentication?

Indexing - why don't u use bleve?

It's actually almost ready! Check out the ponzu-dev branch or look at the compare between it and master for the implementation.

I would love to get some feedback as a first time Bleve user.

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!

as a web server, can I use this with an Ruby on Rails application?

Sure! Just think of Ponzu as a JSON web service and fetch/put data from your controllers or models.

looks interesting

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact