mirror of https://github.com/grpc/grpc.io.git
Begin cleaning up blog posts
Signed-off-by: lucperkins <lucperkins@gmail.com>
This commit is contained in:
lucperkins
parent
36dfa776f2
commit
fc4acb6d68
|
|
@ -1,27 +0,0 @@
|
|||
---
|
||||
attribution: Mugur Marculescu, gRPC
|
||||
date: "2015-10-26T00:00:00Z"
|
||||
published: true
|
||||
title: gRPC releases Beta, opening door for use in production environments.
|
||||
url: blog/beta_release
|
||||
---
|
||||
|
||||
<p>
|
||||
The gRPC team is excited to announce the immediate availability of gRPC Beta. This release marks an important point in API stability and going forward most API changes are expected to be additive in nature. This milestone opens the door for gRPC use in production environments.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
We’re also taking a big step forward in improving the installation process. Over the past few weeks we’ve rolled out gRPC packages to <a href="https://packages.debian.org/jessie-backports/libgrpc0">Debian Stable/Backports</a>. Installation in most cases is now a two line install using the Debian package and available language specific package managers (<a href="https://search.maven.org/#artifactdetails%7Cio.grpc%7Cgrpc-core%7C0.9.0%7Cjar">maven</a>, <a href="https://pypi.python.org/pypi/grpcio">pip</a>, <a href="https://rubygems.org/gems/grpc">gem</a>, <a href="https://packagist.org/packages/grpc/grpc">composer</a>, <a href="https://pecl.php.net/package/gRPC">pecl</a>, <a href="https://www.npmjs.com/package/grpc">npm</a>, <a href="https://www.nuget.org/packages/Grpc/">nuget</a>, <a href="https://cocoapods.org/pods/gRPC">pod</a>). In addition <a href="https://hub.docker.com/r/grpc/">gRPC docker images</a> are now available on Docker Hub.
|
||||
</p>
|
||||
<p>
|
||||
We’ve updated the <a href="/docs/">documentation</a> on grpc.io to reflect the latest changes and released additional language-specific <a href="/docs/reference/">reference docs</a>. See what’s changed with the Beta release in the release notes on GitHub for <a href="https://github.com/grpc/grpc-java/releases/tag/v0.9.0">Java</a>, <a href="https://godoc.org/google.golang.org/grpc">Go</a> and <a href="https://github.com/grpc/grpc/releases/tag/release-0_11_0">all other</a> languages.
|
||||
</p>
|
||||
<p>
|
||||
In keeping in line with our <a href="/blog/principles">principles</a> and goal to enable highly performant and scalable APIs and microservices on top of HTTP/2, in the coming months, the focus of the gRPC project will be to keep improving performance and stability and adding carefully chosen features for production use cases. Documentation will also be clarified and will continue to improve with new examples and guides.
|
||||
</p>
|
||||
<p>
|
||||
We’ve been very excited to see the community response to gRPC and the various projects starting to use it (<a href="https://coreos.com/blog/etcd-2.2/">etcd v3 experimental api</a>, <a href="https://github.com/gengo/grpc-gateway">grpc-gateway</a> for RESTful APIs and others).
|
||||
</p>
|
||||
<p>
|
||||
We really want to thank everyone who contributed code, gave presentations, adopted the technology and engaged in the community. With your help support we look forward to the 1.0!
|
||||
</p>
|
||||
|
|
@ -1,48 +0,0 @@
|
|||
---
|
||||
attribution: Originally written by Louis Ryan with help from others at Google.
|
||||
date: "2015-09-08T00:00:00Z"
|
||||
published: true
|
||||
title: gRPC Motivation and Design Principles.
|
||||
url: blog/principles
|
||||
---
|
||||
|
||||
<h2>Motivation</h2>
|
||||
|
||||
<p>Google has been using a single general-purpose RPC infrastructure called Stubby to connect the large number of microservices running within and across our data centers for over a decade. Our internal systems have long embraced the microservice architecture gaining popularity today. Having a uniform, cross-platform RPC infrastructure has allowed for the rollout of fleet-wide improvements in efficiency, security, reliability and behavioral analysis critical to supporting the incredible growth seen in that period.
|
||||
</p>
|
||||
|
||||
<p>Stubby has many great features - however, it's not based on any standard and is too tightly coupled to our internal infrastructure to be considered suitable for public release. With the advent of SPDY, HTTP/2, and QUIC, many of these same features have appeared in public standards, together with other features that Stubby does not provide. It became clear that it was time to rework Stubby to take advantage of this standardization, and to extend its applicability to mobile, IoT, and Cloud use-cases.</p>
|
||||
|
||||
<h2>Principles & Requirements</h2>
|
||||
|
||||
<p><strong>Services not Objects, Messages not References</strong> - Promote the microservices design philosophy of coarse-grained message exchange between systems while avoiding the <a href="https://martinfowler.com/articles/distributed-objects-microservices.html">pitfalls of distributed objects</a> and the <a href="https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing">fallacies of ignoring the network</a>.</p>
|
||||
|
||||
<p><strong>Coverage & Simplicity</strong> - The stack should be available on every popular development platform and easy for someone to build for their platform of choice. It should be viable on CPU & memory limited devices. </p>
|
||||
|
||||
<p><strong>Free & Open</strong> - Make the fundamental features free for all to use. Release all artifacts as open-source efforts with licensing that should facilitate and not impede adoption.</p>
|
||||
|
||||
<p><strong>Interoperability & Reach</strong> - The wire-protocol must be capable of surviving traversal over common internet infrastructure.</p>
|
||||
|
||||
<p><strong>General Purpose & Performant</strong> - The stack should be applicable to a broad class of use-cases while sacrificing little in performance when compared to a use-case specific stack.</p>
|
||||
|
||||
<p><strong>Layered</strong> - Key facets of the stack must be able to evolve independently. A revision to the wire-format should not disrupt application layer bindings.</p>
|
||||
|
||||
<p><strong>Payload Agnostic</strong> - Different services need to use different message types and encodings such as protocol buffers, JSON, XML, and Thrift; the protocol and implementations must allow for this. Similarly the need for payload compression varies by use-case and payload type: the protocol should allow for pluggable compression mechanisms.</p>
|
||||
|
||||
<p><strong>Streaming</strong> - Storage systems rely on streaming and flow-control to express large data-sets. Other services, like voice-to-text or stock-tickers, rely on streaming to represent temporally related message sequences.</p>
|
||||
|
||||
<p><strong>Blocking & Non-Blocking</strong> - Support both asynchronous and synchronous processing of the sequence of messages exchanged by a client and server. This is critical for scaling and handling streams on certain platforms.</p>
|
||||
|
||||
<p><strong>Cancellation & Timeout</strong> - Operations can be expensive and long-lived - cancellation allows servers to reclaim resources when clients are well-behaved. When a causal-chain of work is tracked, cancellation can cascade. A client may indicate a timeout for a call, which allows services to tune their behavior to the needs of the client.</p>
|
||||
|
||||
<p><strong>Lameducking</strong> - Servers must be allowed to gracefully shut-down by rejecting new requests while continuing to process in-flight ones.</p>
|
||||
|
||||
<p><strong>Flow-Control</strong> - Computing power and network capacity are often unbalanced between client & server. Flow control allows for better buffer management as well as providing protection from DOS by an overly active peer.</p>
|
||||
|
||||
<p><strong>Pluggable</strong> - A wire protocol is only part of a functioning API infrastructure. Large distributed systems need security, health-checking, load-balancing and failover, monitoring, tracing, logging, and so on. Implementations should provide extensions points to allow for plugging in these features and, where useful, default implementations.</p>
|
||||
|
||||
<p><strong>Extensions as APIs</strong> - Extensions that require collaboration among services should favor using APIs rather than protocol extensions where possible. Extensions of this type could include health-checking, service introspection, load monitoring, and load-balancing assignment.</p>
|
||||
|
||||
<p><strong>Metadata Exchange</strong> - Common cross-cutting concerns like authentication or tracing rely on the exchange of data that is not part of the declared interface of a service. Deployments rely on their ability to evolve these features at a different rate to the individual APIs exposed by services.</p>
|
||||
|
||||
<p><strong>Standardized Status Codes</strong> - Clients typically respond to errors returned by API calls in a limited number of ways. The status code namespace should be constrained to make these error handling decisions clearer. If richer domain-specific status is needed the metadata exchange mechanism can be used to provide that.</p>
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
---
|
||||
attribution: Mark Mandel, Sandeep Dinesh
|
||||
date: "2017-09-14T00:00:00Z"
|
||||
published: true
|
||||
title: The gRPC Meetup Kit
|
||||
url: blog/meetup-kit
|
||||
---
|
||||
|
||||
<p>If you have ever wanted to run an event around <a href="http://grpc.io">gRPC</a>, but didn’t know where to start, or wasn’t sure what content is available - we have released the <a href="https://github.com/grpc-ecosystem/meetup-kit">gRPC Meetup Kit</a>!</p>
|
||||
|
||||
<p>The meetup kit includes a 15 minute presentation on the basic concepts of gRPC, with accompanying <a href="https://docs.google.com/presentation/d/1dgI09a-_4dwBMLyqfwchvS6iXtbcISQPLAXL6gSYOcc/edit?usp=sharing">slides</a> and <a href="https://www.youtube.com/watch?v=UVsIfSfS6I4">video</a> for either reference or playback, as well as a <a href="https://codelabs.developers.google.com/codelabs/cloud-grpc/index.html">45 minute codelab</a> that takes you through the basics of gRPC in <a href="https://nodejs.org">Node.js</a> and <a href="https://golang.org/">Go</a>. At the end of the codelab participants will have a solid understanding of the fundamentals of gRPC.</p>
|
||||
<p>If you are thinking about running a gRPC event, make sure to contact us to receive <a href="https://goo.gl/forms/C3TCtFdobz4ippty2">gRPC stickers</a> and/or organise <a href="https://goo.gl/forms/pvxNwWExr5ApbNst2">office hours over Hangouts with the gRPC team</a>! </p>
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: gRPC releases Beta, opening door for use in production environments
|
||||
attribution: Mugur Marculescu, gRPC
|
||||
date: "2015-10-26"
|
||||
aliases: ["blog/beta_release"]
|
||||
---
|
||||
|
||||
The gRPC team is excited to announce the immediate availability of gRPC Beta. This release marks an important point in API stability and going forward most API changes are expected to be additive in nature. This milestone opens the door for gRPC use in production environments.
|
||||
|
||||
We’re also taking a big step forward in improving the installation process. Over the past few weeks we’ve rolled out gRPC packages to <a href="https://packages.debian.org/jessie-backports/libgrpc0">Debian Stable/Backports</a>. Installation in most cases is now a two line install using the Debian package and available language specific package managers (<a href="https://search.maven.org/#artifactdetails%7Cio.grpc%7Cgrpc-core%7C0.9.0%7Cjar">maven</a>, <a href="https://pypi.python.org/pypi/grpcio">pip</a>, <a href="https://rubygems.org/gems/grpc">gem</a>, <a href="https://packagist.org/packages/grpc/grpc">composer</a>, <a href="https://pecl.php.net/package/gRPC">pecl</a>, <a href="https://www.npmjs.com/package/grpc">npm</a>, <a href="https://www.nuget.org/packages/Grpc/">nuget</a>, [pod](https://cocoapods.org/pods/gRPC)). In addition [gRPC docker images](https://hub.docker.com/r/grpc) are now available on Docker Hub.
|
||||
|
||||
|
||||
We’ve updated the [documentation](/docs) on grpc.io to reflect the latest changes and released additional language-specific [reference docs](/docs/reference). See what’s changed with the Beta release in the release notes on GitHub for [Java](https://github.com/grpc/grpc-java/releases/tag/v0.9.0), [Go](https://godoc.org/google.golang.org/grpc), and [all other](https://github.com/grpc/grpc/releases/tag/release-0_11_0) languages.
|
||||
|
||||
In keeping in line with our [principles](../principles) and goal to enable highly performant and scalable APIs and microservices on top of HTTP/2, in the coming months, the focus of the gRPC project will be to keep improving performance and stability and adding carefully chosen features for production use cases. Documentation will also be clarified and will continue to improve with new examples and guides.
|
||||
|
||||
|
||||
We’ve been very excited to see the community response to gRPC and the various projects starting to use it ([etcd v3 experimental API](https://coreos.com/blog/etcd-2.2), [grpc-gateway](https://github.com/gengo/grpc-gateway) for RESTful APIs and others).
|
||||
|
||||
We really want to thank everyone who contributed code, gave presentations, adopted the technology and engaged in the community. With your help support we look forward to the 1.0!
|
||||
|
|
@ -1,14 +1,12 @@
|
|||
---
|
||||
attribution: Originally written by Brandon Phillips with additional content by Lisa
|
||||
Carey and others at Google.
|
||||
Carey and others at Google
|
||||
author: Brandon Phillips
|
||||
company: CoreOS
|
||||
company-link: https://coreos.com
|
||||
date: "2016-05-09T00:00:00Z"
|
||||
published: true
|
||||
date: "2016-05-09"
|
||||
thumbnail: https://avatars2.githubusercontent.com/u/3730757?v=3&s=200
|
||||
title: gRPC with REST and Open APIs
|
||||
url: blog/coreos
|
||||
---
|
||||
|
||||
Our guest post today comes from Brandon Phillips of [CoreOS](https://coreos.com/). CoreOS builds open source projects and products for Linux Containers. Their flagship product for consensus and discovery [etcd](https://coreos.com/etcd/) and their container engine [rkt](https://coreos.com/rkt/) are early adopters of gRPC.
|
||||
|
|
@ -1,10 +1,8 @@
|
|||
---
|
||||
title: "gRPC Meets .NET SDK And Visual Studio: Automatic Codegen On Build"
|
||||
author: Kirill 'kkm' Katsnelson
|
||||
author-link: https://github.com/kkm000
|
||||
date: "2018-12-18T00:00:00Z"
|
||||
published: true
|
||||
title: "gRPC Meets .NET SDK And Visual Studio: Automatic Codegen On Build"
|
||||
url: blog/grpc-dotnet-build
|
||||
date: "2018-12-18"
|
||||
---
|
||||
|
||||
As part of Microsoft's move towards its cross-platform .NET offering, they have
|
||||
|
|
@ -1,10 +1,8 @@
|
|||
---
|
||||
title: .NET Core ❤ gRPC
|
||||
author: Sourabh Shirhatti
|
||||
author-link: https://twitter.com/sshirhatti
|
||||
date: "2019-09-23T00:00:00Z"
|
||||
published: true
|
||||
title: .NET Core ❤ gRPC
|
||||
url: blog/grpc-on-dotnetcore
|
||||
date: "2019-09-23"
|
||||
---
|
||||
|
||||
_This is a guest post by [Sourabh Shirhatti](https://twitter.com/sshirhatti), a Program Manager on the .NET team at Microsoft._
|
||||
|
|
@ -1,20 +1,19 @@
|
|||
---
|
||||
title: gRPC - now with easy installation
|
||||
attribution: Originally written by Lisa Carey with help from others at Google.
|
||||
date: "2016-04-04T00:00:00Z"
|
||||
title: gRPC - now with easy installation.
|
||||
url: blog/installation
|
||||
date: "2016-04-04"
|
||||
---
|
||||
|
||||
Today we are happy to provide an update that significantly simplifies the getting started experience for gRPC.
|
||||
|
||||
* For most languages, **the gRPC runtime can now be installed in a single step via native package managers** such as `npm` for Node.js, `gem` for Ruby and `pip` for Python. Even though our Node, Ruby and Python runtimes are wrapped on gRPC's C core, users now don't need to explicitly pre-install the C core library as a package in most Linux distributions. We autofetch it for you :-).
|
||||
|
||||
* **For Java, we have simplified the steps needed to add gRPC support to your build tools** by providing plugins for Maven and Gradle. These let you easily depend on the core runtime to deploy or ship generated libraries into production environments.
|
||||
|
||||
* You can also use our Dockerfiles to use these updated packages - deploying microservices built on gRPC should now be a very simple experience.
|
||||
|
||||
<!--more-->
|
||||
|
||||
* For most languages, **the gRPC runtime can now be installed in a single step via native package managers** such as `npm` for Node.js, `gem` for Ruby and `pip` for Python. Even though our Node, Ruby and Python runtimes are wrapped on gRPC's C core, users now don't need to explicitly pre-install the C core library as a package in most Linux distributions. We autofetch it for you :-).
|
||||
|
||||
* **For Java, we have simplified the steps needed to add gRPC support to your build tools** by providing plugins for Maven and Gradle. These let you easily depend on the core runtime to deploy or ship generated libraries into production environments.
|
||||
|
||||
* You can also use our Dockerfiles to use these updated packages - deploying microservices built on gRPC should now be a very simple experience.
|
||||
|
||||
The installation story is not yet complete: we are now focused on improving your development experience by packaging our protocol buffer plugins in the same way as the gRPC runtime. This will simplify code generation and setting up your development environment.
|
||||
|
||||
### Want to try it?
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
title: The gRPC Meetup Kit
|
||||
date: "2017-09-14"
|
||||
attribution: Mark Mandel, Sandeep Dinesh
|
||||
---
|
||||
|
||||
If you have ever wanted to run an event around [gRPC](/), but didn't know where to start, or weren't sure what content is available - we have released the [gRPC Meetup Kit](https://github.com/grpc-ecosystem/meetup-kit)!
|
||||
|
||||
The meetup kit includes a 15 minute presentation on the basic concepts of gRPC, with accompanying [slides](https://docs.google.com/presentation/d/1dgI09a-_4dwBMLyqfwchvS6iXtbcISQPLAXL6gSYOcc/edit?usp=sharing) and [video](https://www.youtube.com/watch?v=UVsIfSfS6I4) for either reference or playback, as well as a [45-minute codelab](https://codelabs.developers.google.com/codelabs/cloud-grpc/index.html) that takes you through the basics of gRPC in [Node.js](https://nodejs.org) and [Go](https://golang.org). At the end of the codelab participants will have a solid understanding of the fundamentals of gRPC.
|
||||
|
||||
If you are thinking about running a gRPC event, make sure to contact us to receive [gRPC stickers](https://goo.gl/forms/C3TCtFdobz4ippty2) and/or organise [office hours over Hangouts with the gRPC team](https://goo.gl/forms/pvxNwWExr5ApbNst2)!
|
||||
|
|
@ -0,0 +1,77 @@
|
|||
---
|
||||
title: gRPC Motivation and Design Principles
|
||||
date: "2015-09-08"
|
||||
attribution: Originally written by Louis Ryan with help from others at Google
|
||||
---
|
||||
|
||||
## Motivation
|
||||
|
||||
Google has been using a single general-purpose RPC infrastructure called Stubby to connect the large number of microservices running within and across our data centers for over a decade. Our internal systems have long embraced the microservice architecture gaining popularity today. Having a uniform, cross-platform RPC infrastructure has allowed for the rollout of fleet-wide improvements in efficiency, security, reliability and behavioral analysis critical to supporting the incredible growth seen in that period.
|
||||
|
||||
Stubby has many great features - however, it's not based on any standard and is too tightly coupled to our internal infrastructure to be considered suitable for public release. With the advent of SPDY, HTTP/2, and QUIC, many of these same features have appeared in public standards, together with other features that Stubby does not provide. It became clear that it was time to rework Stubby to take advantage of this standardization, and to extend its applicability to mobile, IoT, and Cloud use-cases.</p>
|
||||
|
||||
## Principles & Requirements
|
||||
|
||||
### Services not Objects, Messages not References
|
||||
|
||||
Promote the microservices design philosophy of coarse-grained message exchange between systems while avoiding the [pitfalls of distributed objects](https://martinfowler.com/articles/distributed-objects-microservices.html) and the [fallacies of ignoring the network](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing).
|
||||
|
||||
### Coverage & Simplicity
|
||||
|
||||
The stack should be available on every popular development platform and easy for someone to build for their platform of choice. It should be viable on CPU and memory-limited devices.
|
||||
|
||||
### Free & Open
|
||||
|
||||
Make the fundamental features free for all to use. Release all artifacts as open-source efforts with licensing that should facilitate and not impede adoption.
|
||||
|
||||
### Interoperability & Reach
|
||||
|
||||
The wire protocol must be capable of surviving traversal over common internet infrastructure.
|
||||
|
||||
### General Purpose & Performant
|
||||
|
||||
The stack should be applicable to a broad class of use-cases while sacrificing little in performance when compared to a use-case specific stack.
|
||||
|
||||
### Layered
|
||||
|
||||
Key facets of the stack must be able to evolve independently. A revision to the wire-format should not disrupt application layer bindings.
|
||||
|
||||
### Payload Agnostic
|
||||
|
||||
Different services need to use different message types and encodings such as protocol buffers, JSON, XML, and Thrift; the protocol and implementations must allow for this. Similarly the need for payload compression varies by use-case and payload type: the protocol should allow for pluggable compression mechanisms.
|
||||
|
||||
### Streaming
|
||||
|
||||
Storage systems rely on streaming and flow-control to express large data-sets. Other services, like voice-to-text or stock-tickers, rely on streaming to represent temporally related message sequences.
|
||||
|
||||
### Blocking & Non-Blocking
|
||||
|
||||
Support both asynchronous and synchronous processing of the sequence of messages exchanged by a client and server. This is critical for scaling and handling streams on certain platforms.
|
||||
|
||||
### Cancellation & Timeout
|
||||
|
||||
Operations can be expensive and long-lived - cancellation allows servers to reclaim resources when clients are well-behaved. When a causal-chain of work is tracked, cancellation can cascade. A client may indicate a timeout for a call, which allows services to tune their behavior to the needs of the client.
|
||||
|
||||
### Lameducking
|
||||
|
||||
Servers must be allowed to gracefully shut-down by rejecting new requests while continuing to process in-flight ones.
|
||||
|
||||
### Flow Control
|
||||
|
||||
Computing power and network capacity are often unbalanced between client ands server. Flow control allows for better buffer management as well as providing protection from DOS by an overly active peer.
|
||||
|
||||
### Pluggable
|
||||
|
||||
A wire protocol is only part of a functioning API infrastructure. Large distributed systems need security, health-checking, load-balancing and failover, monitoring, tracing, logging, and so on. Implementations should provide extensions points to allow for plugging in these features and, where useful, default implementations.
|
||||
|
||||
### Extensions as APIs
|
||||
|
||||
Extensions that require collaboration among services should favor using APIs rather than protocol extensions where possible. Extensions of this type could include health-checking, service introspection, load monitoring, and load-balancing assignment.
|
||||
|
||||
### Metadata Exchange
|
||||
|
||||
Common cross-cutting concerns like authentication or tracing rely on the exchange of data that is not part of the declared interface of a service. Deployments rely on their ability to evolve these features at a different rate to the individual APIs exposed by services.
|
||||
|
||||
### Standardized Status Codes
|
||||
|
||||
Clients typically respond to errors returned by API calls in a limited number of ways. The status code namespace should be constrained to make these error handling decisions clearer. If richer domain-specific status is needed the metadata exchange mechanism can be used to provide that.
|
||||
|
|
@ -1,14 +1,13 @@
|
|||
---
|
||||
title: Why we have decided to move our APIs to gRPC
|
||||
attribution: Originally written by Dale Hopkins with additional content by Lisa Carey
|
||||
and others at Google.
|
||||
author: Dale Hopkins
|
||||
company: Vendasta
|
||||
company-link: https://vendasta.com
|
||||
date: "2016-07-25T00:00:00Z"
|
||||
date: "2016-07-25"
|
||||
published: false
|
||||
thumbnail: ../img/vend-icon.png?raw=true
|
||||
title: Why we have decided to move our APIs to gRPC
|
||||
url: blog/vendasta
|
||||
---
|
||||
|
||||
Our guest post today comes from Dale Hopkins, CTO of [Vendasta](https://vendasta.com/). Vendasta started out 8 years ago as a point solution provider of products for small business. From the beginning we partnered with media companies and agencies who have armies of salespeople and existing relationships with those businesses to sell our software. It is estimated that over 30 million small businesses exist in the United States alone, so scalability of our SaaS solution was considered one of our top concerns from the beginning and it was the reason we started with Google App Engine (Python GAE) and Datastore. This solution worked really well for us as our system scaled from hundreds to hundreds of thousands of end users. We also scaled our offering from a point solution to an entire platform with multiple products and the tools for partners to manage their sales of those products during this time.
|
||||
|
|
@ -5,7 +5,7 @@
|
|||
<section class="hero is-medium is-primary has-background-image">
|
||||
<div class="hero-body">
|
||||
<div class="container">
|
||||
<p class="title is-size-1 is-size-2-mobile has-text-weight-bold{{ if $desc }} is-spaced{{ end }}">
|
||||
<p class="title is-size-1 is-size-2-mobile has-text-weight-bold{{ if or $desc $attr }} is-spaced{{ end }}">
|
||||
{{ $title }}
|
||||
</p>
|
||||
|
||||
|
|
@ -15,6 +15,12 @@
|
|||
</p>
|
||||
{{ end }}
|
||||
|
||||
{{ with $desc }}
|
||||
<p class="subtitle is-size-3 is-size-4-mobule has-text-weight-light">
|
||||
{{ . }}
|
||||
</p>
|
||||
{{ end }}
|
||||
|
||||
<p class="is-size-4 is-size-mobile has-text-weight-medium">
|
||||
{{ $date }}
|
||||
</p>
|
||||
|
|
|
|||
Loading…
Reference in New Issue